消息隊列作為一種基礎的抽象數據結構，被廣泛應用在各類編程與系統設計中。

同步VS異步

通信的一個基本問題是：發(fā)出去的消息什么時候需要被接收到？這個問題引出了兩個基礎概念：“同步通信”和“異步通信”。根據理論抽象模型，同步通信和異步通信最本質的差別來自于時鐘機制的有無。同步通信的雙方需要一個校準的時鐘，異步通信的雙方不需要時鐘。現實的情況是，沒有完全校準的時鐘，所以沒有絕對的同步通信。同樣，絕對異步通信意味著無法控制一個發(fā)出去的消息被接收到的時間點，無期限的等待一個消息顯然毫無實際意義。所以，實際編程中所有的通信既不是“同步通信”也不是“異步通信”；或者說，既是“同步通信”也是“異步通信”。特別是對于應用層的通信，其底層架構可能既包含“同步機制”也包含“異步機制”。判斷“同步”和“異步”消息的標準問題太深，而不適合繼續(xù)展開。這里給一些啟發(fā)式的建議：

• 發(fā)出去的消息是否需要確認，如果不需要確認，更像是異步通信，這種通信有時候也稱為單向通信（One-Way Communication）。

• 如果需要確認，可以根據需要確認的時間長短進行判斷。時間長的更像是異步通信，時間短的更像是同步通信。當然時間長短的概念是純粹的主觀概念，不是客觀標準。

• 發(fā)出去的消息是否阻塞下一個指令的執(zhí)行，如果阻塞，更像是同步，否則，更像是異步。

當分析一個通信需求或者進行通信構架的時候，工程師們被迫作出“同步”還是“異步”的決定。當決策的結論是“異步通信”的時候，分布式隊列編程模型就是一個備選項。

發(fā)送者接收者解耦

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

• 無論是發(fā)送方還是接收方，只需要跟消息中間件通信，接口統一。統一意味著降低開發(fā)成本。

• 在不影響性能的前提下，同一套消息中間件部署，可以被不同業(yè)務共享。共享意味著降低運維成本。

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

消息暫存機制

在進行通信發(fā)送方設計的時候，如果消息無法被迅速處理掉而產生堆積怎么辦、能否被直接拋棄？如果根據需求分析，確認存在消息積存，并且消息不應該被拋棄，就應該考慮分布式隊列編程模型構架，因為隊列可以暫存消息。

如何傳遞

對通信需求進行架構，一系列的基礎挑戰(zhàn)會迎面而來，這包括：

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

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

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

• 吞吐量和響應時間。

• 跨平臺兼容性。

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

性能

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

• 是否需要確認機制，即寫入隊列后，或從隊列讀取后，是否需要進行確認。確認機制對響應時間的影響往往很大。
• 能否批處理，即消息能否批量讀取或者寫入。批量操作可以大大減少應用程序與消息中間件的交互次數和消息傳遞量，大大提高吞吐量。
• 能否進行分區(qū)（Partition）。將某一主題消息隊列進行分區(qū)，同一主題消息可以有多臺機器并行處理。這不僅僅能影響消息中間件的吞吐量，還決定著消息中間件是否具備良好的可伸縮性（Scalability）。
• 是否需要進行持久化。將消息進行持久化往往會同時影響吞吐量和響應時間。

可靠性

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

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

高可靠的消息中間件應該確保從發(fā)送者接收到的消息不會丟失。中間件代理服務器的宕機并不是小概率事件，所以保存在內存中的消息很容易發(fā)生丟失。大部分的消息中間件都依賴于消息的持久化去降低消息丟失損失，即將接收到的消息寫入磁盤。即使提供持久化，仍有兩個問題需要考慮：

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

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

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

客戶端接口所支持語言

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

總結

相關技術與理論參考：

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

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

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

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

如有想了解更多軟件研發(fā) , 系統 IT集成 , 企業(yè)信息化，項目管理，企業(yè)管理 等資訊，請關注我的微信訂閱號：

 

作者：Petter Liu
出處：http://www.rzrgm.cn/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。
該文章也同時發(fā)布在我的獨立博客中-Petter Liu Blog。