消息中間件選型

    消息中間件對目前大中型互聯網來講是很是重要的，在業務數據流動中僅次於RPC服務調用，擔負着愈來愈複雜的網站業務從主流程上解耦的重要責任；
    從目前互聯網對消息中間件的需求來看應該分爲兩種類型，一種是和錢相關的需求，一種是和錢無關的需求；和錢相關的需求消息的可靠性是放在第一位的，和錢無關的需求是速度放在第一位的，但這兩種需求又是矛盾的，很難設計出一種既可靠又高效的系統，除非將兩套方案捏合成一個系統，經過配置來選擇不一樣方案，但從實現上說仍是兩種實現。因此目前業界有幾種不一樣的設計方式來知足不一樣的需求。

下面看幾種典型的實現方案：

一、以ActiveMQ爲表明的可靠性優先的設計原理：簡單、輕量、易部署(JMS Provider負責消息路由)

     此種方案將全部的消息數據和消息的發送狀態都存儲在消息服務器上，能夠在消息服務上經過多種手段來保證消息的可靠性，但增長了衆多複雜的可靠性保證手段後，消息從發佈者到訂閱者的速度勢必會受到影響；此種方式發佈者將消息推向消息服務器，消息服務器再將消息推向訂閱者，爲消息發送策略提供了很好的可擴展性；

ActiveMQ參見：http://manzhizhen.iteye.com/category/318342

二、以KafKa爲表明的速度優先的設計原理

     此種方式將消息的發送狀態保存在客戶端，同時客戶端用拉的模式從消息服務器上獲取消息，因爲是順序讀，同時還採起了不少保證速度的策略，如zero-copy，因此此種方案速度比較快，但犧牲了不少可靠性方面的保證，比較適合Web2.0網站，這些網站對消息的可靠性要求不是很高，同時因爲產生了大量的和用戶狀態相關的消息，須要一個高效的系統來處理這些消息；另外這種方案也比較適合日誌消息的收集；

 

• broker： 緩存代理，kafka集羣中的一個kafka服務節點稱爲一個broker，主要存儲消息數據。不是主從關係，各個broker在集羣中地位同樣，能夠隨意的增刪broker節點。
• topic： kafka 處理的消息的分類。
• partition： 一個topic在broker中被分爲1個或者多個partition，分區在建立topic的時候指定。
• message： 消息（offset，MessageSize，data），是通訊的基本單位，每一個消息都屬於一個partition。
• producer： 生產者，向kafka的一個topic發佈消息。
• consumer： 消費者，訂閱topic並處理其發佈的消息。
• zookeeper： 協調kafka的正常運行。
• push-and-pull : Kafka中的Producer和consumer採用的是push-and-pull模式，即Producer只管向broker push消息，consumer只管從broker pull消息，二者對消息的生產和消費是異步的。

消息的發送流程以下：

• 一、Producer： 能夠根據用戶自定義算法來根據消息的key來計算輸入到哪一個partition。能夠指定同步異步（producer.type），異步發送模式容許進行批量發送，先將消息緩存在內存中，而後一次請求批量發送出去。（queue.buffering.max.ms=5000、queue.buffering.max.messages=10000）。
• 二、broker 爲了減小磁盤寫入的次數,broker會將消息暫時buffer起來,當消息的個數達到必定閥值或者過了必定的時間間隔時,再flush到磁盤,這樣減小了磁盤IO調用的次數。配置（log.flush.interval…、log.retention…默認7天）。
• 三、kafka： 集羣接收到Producer發過來的消息後，將其持久化到硬盤，並保留消息指定時長(可配置)，不關注消息是否被消費。
• 四、Consumer： 從kafka集羣pull數據，並控制獲取消息的offset。每一個consumer屬於一個consumer group，能夠指定組id。Group.id。

 

三、傳統的解耦方案

消息隊列中間件的技術選型分析請參見：http://www.cnblogs.com/lsx1993/p/4657897.html