产品经理懂点技术之:系统间是怎么同步信息的

7 评论 9678 浏览 122 收藏 12 分钟

本文将会从一个最简单的请求讲起,从同步异步请求,到轮询回调,再到更先进的解决方案消息队列,用以介绍系统间不同的同步信息方式。

最近产品汪正在负责自家系统跟某个供应商的对接,经常听到技术们关于订单状态同步的事情吵得不可开交。

我方程序猿:你们系统状态为啥都不同步回给我们啊,这我们怎么知道状态变了啊

供应商对接人员:你们自己轮询啊

我方程序猿:这样很不靠谱啊,你们回调一下不行么

供应商对接人员:改这不要时间么

我方程序猿:你们怎么一些地方有回调一些地方没有啊

供应商对接人员:不同时期同事写的嘛……

我方程序猿:*&¥%*&%……

等到对接功能终于提测后,产品汪就问了一下程序猿哥哥,轮询和回调是什么,他们有什么区别呢?

下文将会从一个最简单的请求讲起,从同步异步请求,到轮询回调,再到更先进的解决方案消息队列,用以介绍系统间不同的同步信息方式。

一个简单的请求 Request

程序猿哥哥说,要晓得为什么要轮询和回调,首先要知道两个系统间信息是怎么交互的。例如你的手机APP要登录,APP就要把输入的账号密码发给后台,后台判断发现这个账号已经注册了,密码也匹配,就会告诉APP登录成功。

A发给B一些东西,B返回处理的结果,这就是一个简单的信息请求(request)的过程。

小汪说,这个我知道啊。

于是程序猿哥哥又说,刚才这种请求,我们称之为“同步请求”,就是你要什么,一会儿对方就给你发了回来,但事实上万一处理的逻辑多且复杂,可能信息没那么快返回,你说咋办?

小汪说,在界面上一直loading等待中,转圈圈么?

程序猿哥哥大笑,说好的用户体验呢?在这种情况下,我们就继续做别的事情,然后对方返回了消息来,我们再接着做原来的事情,这样体验不就更好了么。

于是我们引进了“异步”的请求, 我方请求对方处理某个事情后,在等待过程中我们还可以继续做点别事情,直至对方返回了内容,这样再接上,用户体验就比转圈圈等待好多了。

产品汪:原来是这样啊,那这又跟轮询、回调有什么关系么?

轮询 Polling

程序猿哥哥说:耐心点小伙子,你这样不耐烦的样子,就像极了轮询。

当我方系统,如图中橙色的手机,将信息发给另外一个系统后, 即图中蓝色的服务器,需要处理一阵子才有结果。例如:

  • 用户下了一个订单要商家发货
  • 一个合作伙伴在系统中提交了合同申请,需要等我方运营同事审批
  • 一个员工在手机上提交了请假流程,需要等领导在OA里同意

这时候,对方系统不可能立即有结果,我方系统就会不断的追问对方,商家发货了没啊,运营审批了没啊,领导同意了没啊,如果对方信息没有更新,或者事情还没有处理完,则返回未完成的消息。然后我方就继续不断的追问,直到对方答复,发货啦、审批啦、同意啦,然后我方就更新自己的信息状态,流程截止。

小汪说,原来就是不断的烦对方呀。

程序猿说,是的,当对方不能立即处理完成时,就需要我方通过轮询不断向对方查询订单状态是否有更新。又或者我们的系统需要轮播显示最新的新闻、通知、广告时,我们也要用到这个技术,不断向服务器查询有没有新的内容。

回调 Callback

小汪说,轮询我算懂了,就是不断的问不断的问,就可以获得最新的信息、订单状态等等内容,这个是挺实用的。但是这样不会很耗费资源么,占网速、费电之类的?

程序猿回答,是啊,所以我们就有一个新的办法,叫做“回调”,对方做好了告诉我们一声不就好了么,这样我们就省时省力啦。

产品汪说,那对方做好了能直接说一声,既然有这么好的方案,为什么还要用轮询呢?

程序猿继续回答道,就像两个人打电话一样,如果对方沉默了很久,你会不会问“喂喂喂,还在么?”,又或者对方说了什么,由于信号不好,你没听到咋办?

产品汪:搜嘎,回调要求双方都在线,而且网络通畅,如果自己掉线了或者双方谁网络不好,可能就会错过对方回复的内容了。那轮询、回调必须搭配着用啊,那岂不是很复杂了?

程序猿补充道,现在很多平台都有“多次回调”的机制,就是把结果重复发多几次,免得我方没收到,但是只用回调不能根治你刚才说的问题,万一我全程不在线呢是吧,而且多次回调还有”幂等性“的一些问题,这个以后遇到再给你细说。

消息列队 Message Queue

产品汪就好奇了,问程序猿哥哥,那有没有既省事,又保障消息一定送达的方案呢?就是类似把轮询和回调结合的方案。

程序猿说,有啊,你还记得很久前有些聊天软件有“已读”的功能么?

产品汪说,以前确实有段时间这个概念比较火,发出去的消息可以知道对方有没有看,其实现在阿里旺旺跟卖家聊天也有这个功能。

程序猿说,把回调、轮询相结合的方案,其实就类似已读,我们找个服务器,把请求内容都放在上面,像个聊天对话列表一样,我们称之为“消息队列”(Message Queue,简称MQ)。有消息的时候就通知我一下,如果我不在线,下次上线的时候消息依然还在那里。我看完了可以点个“朕已阅”,然后对方就知道我已经收到消息了。

产品汪说,这个有意思啊,这样就不会错过任何对方回复的东西啦!那为什么不都用消息列队呢?这样能减少系统间同步订单状态出错的概率啊。

程序猿说,要做MQ,得要搭建个消息服务器。从同步请求、到异步请求,再到轮询/回调,我们的系统在越来越复杂,如果我们面对的不是很复杂的内容处理,大部分时候都能做到立即返回结果,那可能轮询、回调都不需要,我们要根据实际需求设计技术方案呀。复杂的技术流程不仅仅占用开发时间,还会影响用户对程序速度的感觉,如果一个简单的请求也走MQ的话,那就太曲折了,没这个必要。

产品汪:原来如此啊,还是多快好省的问题啊哈哈哈哈。

程序猿又补充到,就像我们现在很多个子系统,各种订单支付、订单发货、商家、商品、佣金状态等等,又跟多个供应商系统对接着,很多信息的修改都要有审批流程,审批完成之后才会把状态同步回去,这时候我们就可以尝试建立一套MQ服务器,利用MQ来确保各个子系统间信息的同步。

总结

在与程序猿哥哥聊完后,产品汪赶紧跑去赶地铁回家吃晚饭,路上小汪就在想,其实不同系统同步信息有以下几个问题:

  • 时效性:有些内容需要审批完,或者进行一系列复杂逻辑才能处理完的,不能让一方系统在干等。
  • 可靠性:例如一个订单在我这边已经审批完了,如何确保其他人也知道这个结果,信息同步要到位,且准确,不能让其他人收不到订单状态更新,或者收到错误的结果,例如已审批通过但是却收到审批不通过的结果。
  • 低功耗:用技术的话说可能是“高性能”,不能浪费太多资源在查询状态更新上,系统中有上万个订单要更新状态同步给我们的供应商时,方案不对可能系统就卡死了。

如果一个请求的内容特别重要,而且对方又不能立刻给结果时,消息队列MQ是一个不错的选择,这样我就不怕错过消息了。如果只是些普通的请求,处理很快的,又或者用户不能等的,那就用简单的请求就好了,看来做技术也是要按具体需求来设计方案的呀。

 

本文由 @iCheer 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
3人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 干货,作者一定是大咖才能做到这么通俗

    回复
  2. 讲的太清楚啦

    回复
  3. 多多益善,多多益善哈

    回复
  4. 这篇太赞了~

    回复
  5. 学习了~写得简单易懂,深入浅出~

    回复
  6. 很棒的分享,谢谢~

    回复
  7. 学习了!

    回复