消息隊列作為一種基礎的抽象數據結構，被廣泛應用在各類編程與系統設計中。 同步VS非同步 通信的一個基本問題是：發出去的消息什麼時候需要被接收到？這個問題引出了兩個基礎概念：“同步通信”和“非同步通信”。根據理論抽象模型，同步通信和非同步通信最本質的差別來自於時鐘機制的有無。同步通信的雙方需要一個校準的時鐘... ...
消息隊列作為一種基礎的抽象數據結構，被廣泛應用在各類編程與系統設計中。
同步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集成 , 企業信息化，項目管理，企業管理 等資訊，請關註我的微信訂閱號：
![MegadotnetMicroMsg_thumb1_thumb1_thu[1]](http://images.cnitblog.com/blog/15172/201412/061436383581137.jpg "MegadotnetMicroMsg_thumb1_thumb1_thu[1]")
作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。
該文章也同時發佈在我的獨立博客中-Petter Liu Blog。
