最近產品汪正在負責自家系統跟某個供應商的對接，經常聽到技術們關於訂單狀態同步的事情吵得不可開交。
我方程序猿：你們系統狀態爲啥都不同步回給我們啊，這我們怎麼知道狀態變了啊
供應商對接人員：你們自己輪詢啊
我方程序猿：這樣很不靠譜啊，你們回調一下不行麼
供應商對接人員：改這不要時間麼
我方程序猿：你們怎麼一些地方有回調一些地方沒有啊
供應商對接人員：不同時期同事寫的嘛……
我方程序猿：*&￥%*&%……
等到對接功能終於提測後，產品汪就問了一下程序猿哥哥，輪詢和回調是什麼，他們有什麼區別呢？
一個簡單的請求 Request
程序猿哥哥說，要曉得爲什麼要輪詢和回調，首先要知道兩個系統間信息是怎麼交互的。例如你的手機APP要登錄，APP就要把輸入的賬號密碼發給後臺，後臺判斷髮現這個賬號已經註冊了，密碼也匹配，就會告訴APP登錄成功。
A發給B一些東西，B返回處理的結果，這就是一個簡單的信息請求（request）的過程。
小汪說，這個我知道啊。
於是程序猿哥哥又說，剛纔這種請求，我們稱之爲“同步請求”，就是你要什麼，一會兒對方就給你發了回來，但事實上萬一處理的邏輯多且複雜，可能信息沒那麼快返回，你說咋辦？
小汪說，在界面上一直loading等待中，轉圈圈麼？
程序猿哥哥大笑，說好的用戶體驗呢？在這種情況下，我們就繼續做別的事情，然後對方返回了消息來，我們再接着做原來的事情，這樣體驗不就更好了麼。
於是我們引進了“異步”的請求， 我方請求對方處理某個事情後，在等待過程中我們可以繼續做別的，直至對方返回了內容，這樣再接上，用戶體驗就比轉圈圈等待好多了。
產品汪：原來是這樣啊，那這又跟輪詢、回調有什麼關係麼？
輪詢 Polling
程序猿哥哥說：耐心點小夥子，你這樣不耐煩的樣子，就像極了輪詢。
當我方系統，如圖中橙色的手機，將信息發給另外一個系統後， 即圖中藍色的服務器，需要處理一陣子纔有結果。例如：
- 用戶下了一個訂單要商家發貨
- 一個合作伙伴在系統中提交了合同申請，需要等我方運營同事審批
- 一個員工在手機上提交了請假流程，需要等領導在OA裏同意
這時候，對方系統不可能立即有結果，我方系統就會不斷的追問對方，商家發貨了沒啊，運營審批了沒啊，領導同意了沒啊，如果對方信息沒有更新，或者事情還沒有處理完，則返回未完成的消息。然後我方就繼續不斷的追問，直到對方答覆，發貨啦、審批啦、同意啦，然後我方就更新自己的信息狀態，流程截止。
小汪說，原來就是不斷的煩對方呀。
程序猿說，是的，當對方不能立即處理完成時，就需要我方通過輪詢不斷向對方查詢訂單狀態是否有更新。又或者我們的系統需要輪播顯示最新的新聞、通知、廣告時，我們也要用到這個技術，不斷向服務器查詢有沒有新的內容。
回調 Callback
小汪說，輪詢我算懂了，就是不斷的問不斷的問，就可以獲得最新的信息、訂單狀態等等內容，這個是挺實用的。但是這樣不會很耗費資源麼，佔網速、費電之類的？
程序猿回答，是啊，所以我們就有一個新的辦法，叫做“回調”，對方做好了告訴我們一聲不就好了麼，這樣我們就省時省力啦。
產品汪說，那對方做好了能直接說一聲，既然有這麼好的方案，爲什麼還要用輪詢呢？
程序猿繼續回答道，就像兩個人打電話一樣，如果對方沉默了很久，你會不會問“喂喂喂，還在麼？”，又或者對方說了什麼，由於信號不好，你沒聽到咋辦？
產品汪：搜嘎，回調要求雙方都在線，而且網絡通暢，如果自己掉線了或者雙方誰網絡不好，可能就會錯過對方回覆的內容了。那輪詢、回調必須搭配着用啊，那豈不是很複雜了？
程序猿補充道，現在很多平臺都有“多次回調”的機制，就是把結果重複發多幾次，免得我方沒收到，但是隻用回調不能根治你剛纔說的問題，萬一我全程不在線呢是吧，而且多次回調還有”冪等性“的一些問題，這個以後遇到再給你細說。
消息列隊 Message Queue
產品汪就好奇了，問程序猿哥哥，那有沒有既省事，又保障消息一定送達的方案呢？就是類似把輪詢和回調結合的方案。
程序猿說，有啊，你還記得很久前有些聊天軟件有”已讀“的功能麼？
產品汪說，以前確實有段時間這個概念比較火，發出去的消息可以知道對方有沒有看，其實現在阿里旺旺跟賣家聊天也有這個功能。
程序猿說，把回調、輪詢相結合的方案，其實就類似已讀，我們找個服務器，把請求內容都放在上面，像個聊天對話列表一樣，我們稱之爲”消息隊列“（Message Queue，簡稱MQ），有消息的時候就通知我一下，如果我不在線，下次上線的時候消息依然還在那裏。我看完了可以點個“朕已閱”，然後對方就知道我已經收到消息了。
產品汪說，這個有意思啊，這樣就不會錯過任何對方回覆的東西啦！那爲什麼不都用消息列隊呢？這樣能減少系統間同步訂單狀態出錯的概率啊。
程序猿說，要做MQ，得要搭建個消息服務器。從同步請求、到異步請求，再到輪詢/回調，我們的系統在越來越複雜，如果我們面對的不是很複雜的內容處理，大部分時候都能做到立即返回結果，那可能輪詢、回調都不需要，我們要根據實際需求設計技術方案呀。複雜的技術流程不僅僅佔用開發時間，還會影響用戶對程序速度的感覺，如果一個簡單的請求也走MQ的話，那就太曲折了，沒這個必要。
產品汪：原來如此啊，還是多快好省的問題啊哈哈哈哈。
程序猿又補充到，就像我們現在很多個子系統，各種訂單支付、訂單發貨、商家、商品、佣金狀態等等，又跟多個供應商系統對接着，很多信息的修改都要有審批流程，審批完成之後纔會把狀態同步回去，這時候我們就可以嘗試建立一套MQ服務器，利用MQ來確保各個子系統間信息的同步。
總結
在與程序猿哥哥聊完後，產品汪趕緊跑去趕地鐵回家喫晚飯，路上小汪就在想，其實不同系統同步信息有以下幾個問題：
- 時效性：有些內容需要審批完，或者進行一系列複雜邏輯才能處理完的，不能讓一方系統在乾等。
- 可靠性：例如一個訂單在我這邊已經審批完了，如何確保其他人也知道這個結果，信息同步要到位，且準確，不能讓其他人收不到訂單狀態更新，或者收到錯誤的結果，例如已審批通過但是卻收到審批不通過的結果。
- 低功耗：用技術的話說可能是“高性能”，不能浪費太多資源在查詢狀態更新上，系統中有上萬個訂單要更新狀態同步給我們的供應商時，方案不對可能系統就卡死了。
如果一個請求的內容特別重要，而且對方又不能立刻給結果時，消息隊列MQ是一個不錯的選擇，這樣我就不怕錯過消息了。如果只是些普通的請求，處理很快的，又或者用戶不能等的，那就用簡單的請求就好了。