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

转载自 人人都是产品经理

作者 @iCheer 原文地址 http://www.woshipm.com/pmd/3625934.html

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

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

我方程序猿：你们系统状态为啥都不同步回给我们啊，这我们怎么知道状态变了啊 供应商对接人员：你们自己轮询啊 我方程序猿：这样很不靠谱啊，你们回调一下不行么 供应商对接人员：改这不要时间么 我方程序猿：你们怎么一些地方有回调一些地方没有啊 供应商对接人员：不同时期同事写的嘛…… 我方程序猿：&￥%&%……

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

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

一个简单的请求 Request

程序猿哥哥说，要晓得为什么要轮询和回调，首先要知道两个系统间信息是怎么交互的。例如你的手机APP要登录，APP就要把输入的账号密码发给后台，后台判断发现这个账号已经注册了，密码也匹配，就会告诉APP登录成功。
A发给B一些东西，B返回处理的结果，这就是一个简单的信息请求（request）的过程。

小汪说，这个我知道啊。

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

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

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

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

产品汪：原来是这样啊，那这又跟轮询、回调有什么关系么？

轮询 Polling

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

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

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

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

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

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

回调 Callback

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

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

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

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

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

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

消息列队 Message Queue

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

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

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

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

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

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

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

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

总结

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

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

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