2019獨角獸企業重金招聘Python工程師標準>>>

##1、選擇推送還是拉取 在消息系統中，一般有兩種消費模式：服務端推送和客戶端拉取。若系統主要面向公網的服務器，采用推送模式，有如下優點 ：

實時性高。從消息的產生到推送，總體平均延時100毫秒，最大不超過200毫秒。

服務器壓力小。相比于拉取模式，每次推送都有數據，避免空輪詢消耗資源。

使用簡便。使用拉取模式，客戶端需要維護消費隊列的位置，以及處理多客戶端同時消費的并發問題。而在推送模式中，這些事情全部由服務器完成，客戶端僅需要啟動SDK監聽消息即可，幾乎沒有使用門檻。

當然，系統也支持客戶端拉取，推送系統會將客戶端的拉取請求轉換為推送請求，直接返回。推送服務器會據此請求推送相應數據到客戶端。即拉取異步化，如果客戶端沒有新產生的數據，不會返回任何數據，減少客戶端的網絡消耗。

##2、消息隊列如何實現消息的順序消費

• 在很多場景下，如何保證隊列信息的有序處理是一個棘手的問題。如下圖，假定分布式隊列保證請求嚴格有序，請求ri2和ri1都是針對同一數據記錄的不同狀態，ri2的狀態比ri1的狀態新。T1、T2、T3和T4代表各個操作發生的時間，并且 T1 < T2 < T3 < T4（"<"代表早于）。

  采用多消費者架構，這兩條記錄被兩個消費者（Consumer1和Consumer2）處理后更新到數據庫里面。Consumer1雖然先讀取ri1但是卻后寫入數據庫，這就導致，新的狀態被老的狀態覆蓋，所以多消費者不保證數據的有序性。

• 所以全局順序是不可能實現的，但是可以實現偏序。

  設計思想參考：https://www.zhihu.com/question/30195969

• 如果push模式的消息隊列，支持分區，單分區只支持一個消費者消費，并且消費者只有確認一個消息消費后才能push送另外一個消息，還要發送者保證全局順序唯一，聽起來也能做順序消息，但成本太高了，尤其是必須每個消息消費確認后才能發下一條消息，這對于本身堆積能力和慢消費就是瓶頸的push模式的消息隊列，簡直是一場災難。 反觀pull模式，如果想做到全局順序消息，就相對容易很多：

  producer對應partition，并且單線程。

  consumer對應partition，消費確認（或批量確認），繼續消費即可。 所以對于日志push送這種最好全局有序，但允許出現小誤差的場景，pull模式非常合適。如果你不想看到通篇亂套的日志~~

  Anyway，需要順序消息的場景還是比較有限的而且成本太高，請慎重考慮。

REF:

• http://tech.meituan.com/distributed_queue_based_programming-optimization.html

• http://tech.meituan.com/mq-design.html

轉載于:https://my.oschina.net/hzchenyh/blog/839269

總結

以上是生活随笔為你收集整理的消息队列的探究的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。