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

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

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

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

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

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

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

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

我方程序猿：*&￥%*&%……

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

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

一个简单的请求 Request

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

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

小汪说，这个我知道啊。

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

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

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

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

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

轮询 Polling

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

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

用户下了一个订单要商家发货

一个合作伙伴在系统中提交了合同申请，需要等我方运营同事审批

一个员工在手机上提交了请假流程，需要等领导在OA里同意

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

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

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

回调 Callback

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

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

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

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