907
互聯網業務場景下消息隊列架構
消息隊列作為一種基礎的抽象數據結構，被廣泛應用在各類編程與係統設計中。
同步VS異步
通信的一個基本問題是：發出去的消息什麼時候需要被接收到？這個問題引出了兩個基礎概念：“同步通信”和“異步通信”。根據理論抽象模型，同步通信和異步通信最本質的差別來自於時鍾機製的有無。同步通信的雙方需要一個校準的時鍾，異步通信的雙方不需要時鍾。現實的情況是，沒有完全校準的時鍾，所以沒有絕對的同步通信。同樣，絕對異步通信意味著無法控製一個發出去的消息被接收到的時間點，無期限的等待一個消息顯然毫無實際意義。所以，實際編程中所有的通信既不是“同步通信”也不是“異步通信”；或者說，既是“同步通信”也是“異步通信”。特別是對於應用層的通信，其底層架構可能既包含“同步機製”也包含“異步機製”。判斷“同步”和“異步”消息的標準問題太深，而不適合繼續展開。這裏給一些啟發式的建議
官網：www.fhadmin.org：
- 發出去的消息是否需要確認，如果不需要確認，更像是異步通信，這種通信有時候也稱為單向通信（One-Way Communication）。
- 如果需要確認，可以根據需要確認的時間長短進行判斷。時間長的更像是異步通信，時間短的更像是同步通信。當然時間長短的概念是純粹的主觀概念，不是客觀標準。
- 發出去的消息是否阻塞下一個指令的執行，如果阻塞，更像是同步，否則，更像是異步。
當分析一個通信需求或者進行通信構架的時候，工程師們被迫作出“同步”還是“異步”的決定。當決策的結論是“異步通信”的時候，分布式隊列編程模型就是一個備選項。
發送者接收者解耦
在進行通信需求分析的時候，需要回答的另外一個基本問題是：消息的發送方是否關心誰來接收消息，或者反過來，消息接收方是否關心誰來發送消息。消息的發送方和接收方不關心對方是誰、以及在哪裏，分布式隊列編程模型就是一個備選項。因為在這種場景下，分布式隊列架構所帶來的解耦能給係統架構帶來這些好處：
- 無論是發送方還是接收方，隻需要跟消息中間件通信，接口統一。統一意味著降低開發成本。
- 在不影響性能的前提下，同一套消息中間件部署，可以被不同業務共享。共享意味著降低運維成本。
- 發送方或者接收方單方麵的部署拓撲的變化不影響對應的另一方。解藕意味著靈活和可擴展。
消息暫存機製 官網：www.fhadmin.org
在進行通信發送方設計的時候，如果消息無法被迅速處理掉而產生堆積怎麼辦、能否被直接拋棄？如果根據需求分析，確認存在消息積存，並且消息不應該被拋棄，就應該考慮分布式隊列編程模型構架，因為隊列可以暫存消息。
如何傳遞
對通信需求進行架構，一係列的基礎挑戰會迎麵而來，這包括：
- 可用性，如何保障通信的高可用。
- 可靠性，如何保證消息被可靠地傳遞。
- 持久化，如何保證消息不會丟失。
- 吞吐量和響應時間。
- 跨平台兼容性。
- 除非工程師對造輪子有足夠的興趣，並且有充足的時間，采用一個滿足各項指標的分布式隊列編程模型就是一個簡單的選擇。
性能
性能主要有兩個方麵需要考慮：吞吐量（Throughput）和響應時間（Latency）。
不同的消息隊列中間件的吞吐量和響應時間相差甚遠，在選型時可以去網上查看一些性能對比報告。
對於同一種中間件，不同的配置方式也會影響性能。主要有如下幾方麵的配置：
- 是否需要確認機製，即寫入隊列後，或從隊列讀取後，是否需要進行確認。確認機製對響應時間的影響往往很大。
- 能否批處理，即消息能否批量讀取或者寫入。批量操作可以大大減少應用程序與消息中間件的交互次數和消息傳遞量，大大提高吞吐量。
- 能否進行分區（Partition）。將某一主題消息隊列進行分區，同一主題消息可以有多台機器並行處理。這不僅僅能影響消息中間件的吞吐量，還決定著消息中間件是否具備良好的可伸縮性（Scalability）。
- 是否需要進行持久化。將消息進行持久化往往會同時影響吞吐量和響應時間。
可靠性
可靠性主要包含：可用性、持久化、確認機製等。
高可用性的消息中間件應該具備如下特征：
- 消息中間件代理服務器（Broker）具有主從備份。即當一台代理服務宕機之後，備用服務器能接管相關的服務。
- 消息中間件中緩存的消息是否有備份、並持久化。
- 根據CAP理論，高可用、高一致性以及網絡分裂不可兼得。根據作者的觀察，大部分的消息中間件在麵臨網絡分裂的情況下下，都很難保證數據的一致性以及可用性。 很多消息中間件都會提供一些可配置策略，讓使用者在可用性和一致性之間做權衡。
高可靠的消息中間件應該確保從發送者接收到的消息不會丟失。中間件代理服務器的宕機並不是小概率事件，所以保存在內存中的消息很容易發生丟失。大部分的消息中間件都依賴於消息的持久化去降低消息丟失損失，即將接收到的消息寫入磁盤。即使提供持久化，仍有兩個問題需要考慮：
- 磁盤損壞問題。長時間來看，磁盤出問題的概率仍然存在。
- 性能問題。與操作內存相比，磁盤I/O的操作性能要慢幾個數量級。頻繁持久化不僅會增加響應時間，也會降低吞吐量。
- 解決這兩個問題的一個解決方案就是：多機確認，定期持久化。即消息被緩存在多台機器的內存中，隻有每台機器都確認收到消息，才跟發送者確認（很多消息中間件都會提供相應的配置選項，讓用戶設置最少需要多少台機器接收到消息）。由於多台獨立機器同時出故障的概率遵循乘法法則，指數級降低，這會大大提高消息中間件的可靠性。
確認機製本質上是通訊的握手機製（Handshaking）。如果沒有該機製，消息在傳輸過程中丟失將不會被發現。高敏感的消息要求選取具備確認機製的消息中間件。當然如果沒有接收到消息中間件確認完成的指令，應用程序需要決定如何處理。典型的做法有兩個：
- 多次重試。
- 暫存到本地磁盤或其它持久化媒介。
客戶端接口所支持語言
采用現存消息中間件就意味著避免重複造輪子。如果某個消息中間件未能提供對應語言的客戶端接口，則意味著極大的成本和兼容性問題。
總結
最後更新：2017-07-23 20:40:54