中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文將會從一個最簡單的請求講起，從同步異步請求，到輪詢回調，再到更先進的解決方案消息隊列，用以介紹系統間不同的同步信息方式。

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

我方程序猿：你們系統狀態為啥都不同步回給我們啊，這我們怎么知道狀態變了啊

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

我方程序猿：這樣很不靠譜啊，你們回調一下不行么

供應商對接人員：改這不要時間么

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

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

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

等到對接功能終于提測后，產品汪就問了一下程序猿哥哥，輪詢和回調是什么，他們有什么區別呢？

下文將會從一個最簡單的請求講起，從同步異步請求，到輪詢回調，再到更先進的解決方案消息隊列，用以介紹系統間不同的同步信息方式。

一個簡單的請求 Request

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

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

小汪說，這個我知道啊。

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

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

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

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

產品汪：原來是這樣啊，那這又跟輪詢、回調有什么關系么？

輪詢 Polling

程序猿哥哥說：耐心點小伙子，你這樣不耐煩的樣子，就像極了輪詢。

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

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

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

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

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

回調 Callback

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

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

產品汪說，那對方做好了能直接說一聲，既然有這么好的方案，為什么還要用輪詢呢？

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

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

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

消息列隊 Message Queue

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

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

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

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

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

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

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

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

總結

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

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

如果一個請求的內容特別重要，而且對方又不能立刻給結果時，消息隊列MQ是一個不錯的選擇，這樣我就不怕錯過消息了。如果只是些普通的請求，處理很快的，又或者用戶不能等的，那就用簡單的請求就好了，看來做技術也是要按具體需求來設計方案的呀。

本文由 @iCheer 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議