產品經理懂點技術之:系統間是怎麼同步信息的

最近產品汪正在負責自家系統跟某個供應商的對接,經常聽到技術們關於訂單狀態同步的事情吵得不可開交。

我方程序猿:你們系統狀態爲啥都不同步回給我們啊,這我們怎麼知道狀態變了啊

供應商對接人員:你們自己輪詢啊

我方程序猿:這樣很不靠譜啊,你們回調一下不行麼

供應商對接人員:改這不要時間麼

我方程序猿:你們怎麼一些地方有回調一些地方沒有啊

供應商對接人員:不同時期同事寫的嘛……

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

等到對接功能終於提測後,產品汪就問了一下程序猿哥哥,輪詢和回調是什麼,他們有什麼區別呢?

 

一個簡單的請求 Request

程序猿哥哥說,要曉得爲什麼要輪詢和回調,首先要知道兩個系統間信息是怎麼交互的。例如你的手機APP要登錄,APP就要把輸入的賬號密碼發給後臺,後臺判斷髮現這個賬號已經註冊了,密碼也匹配,就會告訴APP登錄成功。

A發給B一些東西,B返回處理的結果,這就是一個簡單的信息請求(request)的過程。

 

小汪說,這個我知道啊。

於是程序猿哥哥又說,剛纔這種請求,我們稱之爲“同步請求”,就是你要什麼,一會兒對方就給你發了回來,但事實上萬一處理的邏輯多且複雜,可能信息沒那麼快返回,你說咋辦?

小汪說,在界面上一直loading等待中,轉圈圈麼?

程序猿哥哥大笑,說好的用戶體驗呢?在這種情況下,我們就繼續做別的事情,然後對方返回了消息來,我們再接着做原來的事情,這樣體驗不就更好了麼。

於是我們引進了“異步”的請求, 我方請求對方處理某個事情後,在等待過程中我們可以繼續做別的,直至對方返回了內容,這樣再接上,用戶體驗就比轉圈圈等待好多了。

產品汪:原來是這樣啊,那這又跟輪詢、回調有什麼關係麼?

 

輪詢 Polling

程序猿哥哥說:耐心點小夥子,你這樣不耐煩的樣子,就像極了輪詢。

當我方系統,如圖中橙色的手機,將信息發給另外一個系統後, 即圖中藍色的服務器,需要處理一陣子纔有結果。例如:

  • 用戶下了一個訂單要商家發貨
  • 一個合作伙伴在系統中提交了合同申請,需要等我方運營同事審批
  • 一個員工在手機上提交了請假流程,需要等領導在OA裏同意

這時候,對方系統不可能立即有結果,我方系統就會不斷的追問對方,商家發貨了沒啊,運營審批了沒啊,領導同意了沒啊,如果對方信息沒有更新,或者事情還沒有處理完,則返回未完成的消息。然後我方就繼續不斷的追問,直到對方答覆,發貨啦、審批啦、同意啦,然後我方就更新自己的信息狀態,流程截止。

小汪說,原來就是不斷的煩對方呀。

程序猿說,是的,當對方不能立即處理完成時,就需要我方通過輪詢不斷向對方查詢訂單狀態是否有更新。又或者我們的系統需要輪播顯示最新的新聞、通知、廣告時,我們也要用到這個技術,不斷向服務器查詢有沒有新的內容。

 

回調 Callback

小汪說,輪詢我算懂了,就是不斷的問不斷的問,就可以獲得最新的信息、訂單狀態等等內容,這個是挺實用的。但是這樣不會很耗費資源麼,佔網速、費電之類的?

程序猿回答,是啊,所以我們就有一個新的辦法,叫做“回調”,對方做好了告訴我們一聲不就好了麼,這樣我們就省時省力啦。

產品汪說,那對方做好了能直接說一聲,既然有這麼好的方案,爲什麼還要用輪詢呢?

程序猿繼續回答道,就像兩個人打電話一樣,如果對方沉默了很久,你會不會問“喂喂喂,還在麼?”,又或者對方說了什麼,由於信號不好,你沒聽到咋辦?

產品汪:搜嘎,回調要求雙方都在線,而且網絡通暢,如果自己掉線了或者雙方誰網絡不好,可能就會錯過對方回覆的內容了。那輪詢、回調必須搭配着用啊,那豈不是很複雜了?

程序猿補充道,現在很多平臺都有“多次回調”的機制,就是把結果重複發多幾次,免得我方沒收到,但是隻用回調不能根治你剛纔說的問題,萬一我全程不在線呢是吧,而且多次回調還有”冪等性“的一些問題,這個以後遇到再給你細說。

 

消息列隊 Message Queue

產品汪就好奇了,問程序猿哥哥,那有沒有既省事,又保障消息一定送達的方案呢?就是類似把輪詢和回調結合的方案。

程序猿說,有啊,你還記得很久前有些聊天軟件有”已讀“的功能麼?

產品汪說,以前確實有段時間這個概念比較火,發出去的消息可以知道對方有沒有看,其實現在阿里旺旺跟賣家聊天也有這個功能。

程序猿說,把回調、輪詢相結合的方案,其實就類似已讀,我們找個服務器,把請求內容都放在上面,像個聊天對話列表一樣,我們稱之爲”消息隊列“(Message Queue,簡稱MQ),有消息的時候就通知我一下,如果我不在線,下次上線的時候消息依然還在那裏。我看完了可以點個“朕已閱”,然後對方就知道我已經收到消息了。

產品汪說,這個有意思啊,這樣就不會錯過任何對方回覆的東西啦!那爲什麼不都用消息列隊呢?這樣能減少系統間同步訂單狀態出錯的概率啊。

程序猿說,要做MQ,得要搭建個消息服務器。從同步請求、到異步請求,再到輪詢/回調,我們的系統在越來越複雜,如果我們面對的不是很複雜的內容處理,大部分時候都能做到立即返回結果,那可能輪詢、回調都不需要,我們要根據實際需求設計技術方案呀。複雜的技術流程不僅僅佔用開發時間,還會影響用戶對程序速度的感覺,如果一個簡單的請求也走MQ的話,那就太曲折了,沒這個必要。

產品汪:原來如此啊,還是多快好省的問題啊哈哈哈哈。

程序猿又補充到,就像我們現在很多個子系統,各種訂單支付、訂單發貨、商家、商品、佣金狀態等等,又跟多個供應商系統對接着,很多信息的修改都要有審批流程,審批完成之後纔會把狀態同步回去,這時候我們就可以嘗試建立一套MQ服務器,利用MQ來確保各個子系統間信息的同步。

 

總結

在與程序猿哥哥聊完後,產品汪趕緊跑去趕地鐵回家喫晚飯,路上小汪就在想,其實不同系統同步信息有以下幾個問題:

  • 時效性:有些內容需要審批完,或者進行一系列複雜邏輯才能處理完的,不能讓一方系統在乾等。
  • 可靠性:例如一個訂單在我這邊已經審批完了,如何確保其他人也知道這個結果,信息同步要到位,且準確,不能讓其他人收不到訂單狀態更新,或者收到錯誤的結果,例如已審批通過但是卻收到審批不通過的結果。
  • 低功耗:用技術的話說可能是“高性能”,不能浪費太多資源在查詢狀態更新上,系統中有上萬個訂單要更新狀態同步給我們的供應商時,方案不對可能系統就卡死了。

如果一個請求的內容特別重要,而且對方又不能立刻給結果時,消息隊列MQ是一個不錯的選擇,這樣我就不怕錯過消息了。如果只是些普通的請求,處理很快的,又或者用戶不能等的,那就用簡單的請求就好了。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章