互聯網業務場景下消息隊列架構

消息隊列做爲一種基礎的抽象數據結構，被普遍應用在各種編程與系統設計中。

同步VS異步

通訊的一個基本問題是：發出去的消息何時須要被接收到？這個問題引出了兩個基礎概念：「同步通訊」和「異步通訊」。根據理論抽象模型，同步通訊和異步通訊最本質的差異來自於時鐘機制的有無。同步通訊的雙方須要一個校準的時鐘，異步通訊的雙方不須要時鐘。現實的狀況是，沒有徹底校準的時鐘，因此沒有絕對的同步通訊。一樣，絕對異步通訊意味着沒法控制一個發出去的消息被接收到的時間點，無期限的等待一個消息顯然毫無實際意義。因此，實際編程中全部的通訊既不是「同步通訊」也不是「異步通訊」；或者說，既是「同步通訊」也是「異步通訊」。特別是對於應用層的通訊，其底層架構可能既包含「同步機制」也包含「異步機制」。判斷「同步」和「異步」消息的標準問題太深，而不適合繼續展開。這裏給一些啓發式的建議：

• 發出去的消息是否須要確認，若是不須要確認，更像是異步通訊，這種通訊有時候也稱爲單向通訊（One-Way Communication）。

• 若是須要確認，能夠根據須要確認的時間長短進行判斷。時間長的更像是異步通訊，時間短的更像是同步通訊。固然時間長短的概念是純粹的主觀概念，不是客觀標準。

• 發出去的消息是否阻塞下一個指令的執行，若是阻塞，更像是同步，不然，更像是異步。

當分析一個通訊需求或者進行通訊構架的時候，工程師們被迫做出「同步」仍是「異步」的決定。當決策的結論是「異步通訊」的時候，分佈式隊列編程模型就是一個備選項。

發送者接收者解耦

在進行通訊需求分析的時候，須要回答的另一個基本問題是：消息的發送方是否關心誰來接收消息，或者反過來，消息接收方是否關心誰來發送消息。消息的發送方和接收方不關心對方是誰、以及在哪裏，分佈式隊列編程模型就是一個備選項。由於在這種場景下，分佈式隊列架構所帶來的解耦能給系統架構帶來這些好處：

• 不管是發送方仍是接收方，只須要跟消息中間件通訊，接口統一。統一意味着下降開發成本。

• 在不影響性能的前提下，同一套消息中間件部署，能夠被不一樣業務共享。共享意味着下降運維成本。

• 發送方或者接收方單方面的部署拓撲的變化不影響對應的另外一方。解藕意味着靈活和可擴展。

消息暫存機制

在進行通訊發送方設計的時候，若是消息沒法被迅速處理掉而產生堆積怎麼辦、可否被直接拋棄？若是根據需求分析，確認存在消息積存，而且消息不該該被拋棄，就應該考慮分佈式隊列編程模型構架，由於隊列能夠暫存消息。

如何傳遞

對通訊需求進行架構，一系列的基礎挑戰會迎面而來，這包括：

• 可用性，如何保障通訊的高可用。

• 可靠性，如何保證消息被可靠地傳遞。

• 持久化，如何保證消息不會丟失。

• 吞吐量和響應時間。

• 跨平臺兼容性。

• 除非工程師對造輪子有足夠的興趣，而且有充足的時間，採用一個知足各項指標的分佈式隊列編程模型就是一個簡單的選擇。

性能

性能主要有兩個方面須要考慮：吞吐量（Throughput）和響應時間（Latency）。
不一樣的消息隊列中間件的吞吐量和響應時間相差甚遠，在選型時能夠去網上查看一些性能對比報告。
對於同一種中間件，不一樣的配置方式也會影響性能。主要有以下幾方面的配置：

• 是否須要確認機制，即寫入隊列後，或從隊列讀取後，是否須要進行確認。確認機制對響應時間的影響每每很大。
• 可否批處理，即消息可否批量讀取或者寫入。批量操做能夠大大減小應用程序與消息中間件的交互次數和消息傳遞量，大大提升吞吐量。
• 可否進行分區（Partition）。將某一主題消息隊列進行分區，同一主題消息能夠有多臺機器並行處理。這不只僅能影響消息中間件的吞吐量，還決定着消息中間件是否具有良好的可伸縮性（Scalability）。
• 是否須要進行持久化。將消息進行持久化每每會同時影響吞吐量和響應時間。

可靠性

可靠性主要包含：可用性、持久化、確認機制等。
高可用性的消息中間件應該具有以下特徵：

• 消息中間件代理服務器（Broker）具備主從備份。即當一臺代理服務宕機以後，備用服務器能接管相關的服務。
• 消息中間件中緩存的消息是否有備份、並持久化。
• 根據CAP理論，高可用、高一致性以及網絡分裂不可兼得。根據做者的觀察，大部分的消息中間件在面臨網絡分裂的狀況下下，都很難保證數據的一致性以及可用性。 不少消息中間件都會提供一些可配置策略，讓使用者在可用性和一致性之間作權衡。

高可靠的消息中間件應該確保從發送者接收到的消息不會丟失。中間件代理服務器的宕機並非小几率事件，因此保存在內存中的消息很容易發生丟失。大部分的消息中間件都依賴於消息的持久化去下降消息丟失損失，即將接收到的消息寫入磁盤。即便提供持久化，仍有兩個問題須要考慮：

• 磁盤損壞問題。長時間來看，磁盤出問題的機率仍然存在。
• 性能問題。與操做內存相比，磁盤I/O的操做性能要慢幾個數量級。頻繁持久化不只會增長響應時間，也會下降吞吐量。
• 解決這兩個問題的一個解決方案就是：多機確認，按期持久化。即消息被緩存在多臺機器的內存中，只有每臺機器都確認收到消息，纔跟發送者確認（不少消息中間件都會提供相應的配置選項，讓用戶設置最少須要多少臺機器接收到消息）。因爲多臺獨立機器同時出故障的機率遵循乘法法則，指數級下降，這會大大提升消息中間件的可靠性。

確認機制本質上是通信的握手機制（Handshaking）。若是沒有該機制，消息在傳輸過程當中丟失將不會被發現。高敏感的消息要求選取具有確認機制的消息中間件。固然若是沒有接收到消息中間件確認完成的指令，應用程序須要決定如何處理。典型的作法有兩個：

• 屢次重試。
• 暫存到本地磁盤或其它持久化媒介。

客戶端接口所支持語言

採用現存消息中間件就意味着避免重複造輪子。若是某個消息中間件未能提供對應語言的客戶端接口，則意味着極大的成本和兼容性問題。

總結

相關技術與理論參考：

1. Zookeeper https://zookeeper.apache.org/
2. CAP https://en.wikipedia.org/wiki/CAP_theorem

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

但願對您系統架構，軟件項目開發,運維管理，系統架構與研發管理體系, 信息安全, 企業信息化等有幫助。 其它您可能感興趣的文章：

集中隊列的模式
消息系統架構設計演進
DevOps的基本原則與介紹
Docker與CI持續集成/CD
持續交付中高效率與高質量
持續集成CI與自動化測試
軟件研發工程基礎設施
容器化實踐金融業案例一
雲計算參考架構幾例
微服務與Docker介紹
互聯網直播平臺架構案例一
高可用架構案例一
某互聯網公司廣告平臺技術架構
某大型電商雲平臺實踐
雲計算參考架構幾例
移動應用App測試與質量管理一
全面的軟件測試
著名ERP廠商的SSO單點登陸解決方案介紹一
軟件項目風險管理介紹
企業項目化管理介紹
智能企業與信息化之一
由企業家基本素質想到的
敏捷軟件質量保證的方法與實踐
構建高效的研發與自動化運維
IT運維監控解決方案介紹
IT持續集成之質量管理
人才公司環境與企業文化
企業績效管理系統之平衡記分卡
企業文化、團隊文化與知識共享
高效能的團隊建設
餐飲連鎖公司IT信息化解決方案一

若有想了解更多軟件研發 , 系統 IT集成 , 企業信息化，項目管理，企業管理 等資訊，請關注個人微信訂閱號：

 

做者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。
該文章也同時發佈在個人獨立博客中-Petter Liu Blog。