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

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

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

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

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

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

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

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

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

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

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

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

一个简单的请qiú Request

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

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

小汪说,这个我知道啊。

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

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

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

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

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

轮询 Polling

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

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

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

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

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

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

回调 Callback

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

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

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

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

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

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

消息列队 Message Queue

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

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

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

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

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

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

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

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

总结

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

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

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

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 产品经理懂点技术之:系统间是怎么同步信息的 https://www.xiongfawang.com/2865.html

常见问题

相关文章

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

分享本文封面