訊息佇列作為一種基礎的抽象資料結構，被廣泛應用在各類程式設計與系統設計中。

同步VS非同步

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

• 發出去的訊息是否需要確認，如果不需要確認，更像是非同步通訊，這種通訊有時候也稱為單向通訊（One-Way Communication）。

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

• 發出去的訊息是否阻塞下一個指令的執行，如果阻塞，更像是同步，否則，更像是非同步。

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

傳送者接收者解耦

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

• 無論是傳送方還是接收方，只需要跟訊息中介軟體通訊，介面統一。統一意味著降低開發成本。

• 在不影響效能的前提下，同一套訊息中介軟體部署，可以被不同業務共享。共享意味著降低運維成本。

• 傳送方或者接收方單方面的部署拓撲的變化不影響對應的另一方。解藕意味著靈活和可擴充套件。

訊息暫存機制

在進行通訊傳送方設計的時候，如果訊息無法被迅速處理掉而產生堆積怎麼辦、能否被直接拋棄？如果根據需求分析，確認存在訊息積存，並且訊息不應該被拋棄，就應該考慮分散式佇列程式設計模型構架，因為佇列可以暫存訊息。

如何傳遞

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

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

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

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

• 吞吐量和響應時間。

• 跨平臺相容性。

• 除非工程師對造輪子有足夠的興趣，並且有充足的時間，採用一個滿足各項指標的分散式佇列程式設計模型就是一個簡單的選擇。

效能

效能主要有兩個方面需要考慮：吞吐量（Throughput）和響應時間（Latency）。
不同的訊息佇列中介軟體的吞吐量和響應時間相差甚遠，在選型時可以去網上檢視一些效能對比報告。
對於同一種中介軟體，不同的配置方式也會影響效能。主要有如下幾方面的配置：

• 是否需要確認機制，即寫入佇列後，或從佇列讀取後，是否需要進行確認。確認機制對響應時間的影響往往很大。
• 能否批處理，即訊息能否批量讀取或者寫入。批量操作可以大大減少應用程式與訊息中介軟體的互動次數和訊息傳遞量，大大提高吞吐量。
• 能否進行分割槽（Partition）。將某一主題訊息佇列進行分割槽，同一主題訊息可以有多臺機器並行處理。這不僅僅能影響訊息中介軟體的吞吐量，還決定著訊息中介軟體是否具備良好的可伸縮性（Scalability）。
• 是否需要進行持久化。將訊息進行持久化往往會同時影響吞吐量和響應時間。

可靠性

可靠性主要包含：可用性、持久化、確認機制等。
高可用性的訊息中介軟體應該具備如下特徵：

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

高可靠的訊息中介軟體應該確保從傳送者接收到的訊息不會丟失。中介軟體代理伺服器的宕機並不是小概率事件，所以儲存在記憶體中的訊息很容易發生丟失。大部分的訊息中介軟體都依賴於訊息的持久化去降低訊息丟失損失，即將接收到的訊息寫入磁碟。即使提供持久化，仍有兩個問題需要考慮：

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

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

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

客戶端介面所支援語言

採用現存訊息中介軟體就意味著避免重複造輪子。如果某個訊息中介軟體未能提供對應語言的客戶端介面，則意味著極大的成本和相容性問題。

總結

相關技術與理論參考：

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

如有想了解更多軟體研發 , 系統 IT整合 , 企業資訊化，專案管理，企業管理 等資訊，請關注我的微信訂閱號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連線，否則保留追究法律責任的權利。
該文章也同時釋出在我的獨立部落格中-Petter Liu Blog。