搜嘎(搜嘎是什么意思)

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

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

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

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

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

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

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

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

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

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

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

一个简单的请求 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协议