当前所在位置:主页 > 动态 >

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

发布日期:2021-02-14 22:57 作者:pg电子官网

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  :有些内容需要审批完,或者进行一系列复杂逻辑才能处理完的,不能让一方系统在干等。

  :例如一个订单在我这边已经审批完了,如何确保其他人也知道这个结果,信息同步要到位,且准确,不能让其他人收不到订单状态更新,或者收到错误的结果,例如已审批通过但是却收到审批不通过的结果。

  :用技术的话说可能是“高性能”,不能浪费太多资源在查询状态更新上,系统中有上万个订单要更新状态同步给我们的供应商时,方案不对可能系统就卡死了。

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

  听到很多言论说在中国程序员是吃青春饭的,那么产品经理呢,也吃青春饭吗?

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立9年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。


pg电子官网
pg电子官网