消息中間件對目前大中型互聯網來說是非常重要的，在業務數據流動中僅次于RPC服務調用，擔負著越來越復雜的網站業務從主流程上解耦的重要責任；
??? 從目前互聯網對消息中間件的需求來看應該分為兩種類型，一種是和錢相關的需求，一種是和錢無關的需求；和錢相關的需求消息的可靠性是放在第一位的，和錢無關的需求是速度放在第一位的，但這兩種需求又是矛盾的，很難設計出一種既可靠又高效的系統，除非將兩套方案捏合成一個系統，通過配置來選擇不同方案，但從實現上說還是兩種實現。所以目前業界有幾種不同的設計方式來滿足不同的需求。
下面看看以下幾種典型實現方案：1、以ActiveMQ為代表的可靠性優先的設計原理：

??? 此種方案將所有的消息數據和消息的發送狀態都存儲在消息服務器上，可以在消息服務上通過多種手段來保證消息的可靠性，但增加了眾多復雜的可靠性保證手段后，消息從發布者到訂閱者的速度勢必會受到影響；此種方式發布者將消息推向消息服務器，消息服務器再將消息推向訂閱者，為消息發送策略提供了很好的可擴展性；2、以KafKa為代表的速度優先的設計原理：
??? 此種方式將消息的發送狀態保存在客戶端，同時客戶端用拉的模式從消息服務器上獲取消息，由于是順序讀，同時還采取了很多保證速度的策略，如zero-copy，所以此種方案速度比較快，但犧牲了很多可靠性方面的保證，比較適合Web2.0網站，這些網站對消息的可靠性要求不是很高，同時由于產生了大量的和用戶狀態相關的消息，需要一個高效的系統來處理這些消息；另外這種方案也比較適合日志消息的收集；3、傳統的系解耦方案：
??? 此種方式是不用消息中間件直接用數據庫存儲做的解耦，隨著消息中間件的出現，這種方式的使用越來越少，但現在由于MongoDB和Redis等的興起，一些基于這些Nosql數據庫的消息應用逐漸興起，由于消息數據和消息狀態都存儲在DB上，所以效率和速度在上面兩種方案之間；

? ? 那么有沒有一種更高效的方式呢？

? ? 答案是肯定的，但那可能要進一步降低可靠性！

? ? 看看Facebook的Scribe日志收集系統的原理：

? ? 如果Scribe Server正常工作，Scribe Client將App的日志(可以看成一個消息)推送到Scribe Server端，如果不正常，則寫到本地文件，當Scribe Server恢復正常時再將其推送過去；這里使用本地文件作為緩沖，那么能否綜合Scribe和Kafka的優點來設計一個消息系統(或日志收集系統，改造一下可以互用)，看下面的方案：

? ? 上面的MQ暫且叫他FastMQ吧，①中消息發布端直接寫本地文件，同時消息訂閱者通過Zookeeper協調，向相關消息發布者的Agent拉消息，并在本地記錄消息指針狀態；

? ? 如果嫌在消息發布端開啟MQ?Agent麻煩，那么如②中消息拉取協議使用SCP或FTP協議，用這些Linux必備的協議提供者作為Agent減少開發和部署的難度，在服務訂閱端解析這些協議流，反序列化為消息供業務使用；

? ? 如果覺得消息只存儲在消息發布端的磁盤不可靠，那么如③中可以在消息訂閱者處理不及消息的時候，把消息數據緩沖在消息訂閱端的磁盤上來備份數據，不過這樣做就使系統變的復雜，雖然提高了可靠性，但是速度就會有所降低；

? ? 此種方案可以使消息分散的存儲在業務本身的磁盤上，避免集中存儲相互影響的缺點，同時又可以有效利用業務機器的磁盤(大部分業務機器磁盤基本沒使用)，另外還可以減少一次網絡通信的過程，使從發送到接收的速度更快；但其本身也有不少缺點，要做好監控，避免消息大量積壓的時候業務磁盤過度使用，對業務造成影響。

? ? ?目前我們的監控日志收集系統使用的是和②中類似的方案，消息系統使用的是3方案，后期可能會將可靠性要求高的向1方案過度，可靠性要求不高的向最下面介紹這種過度！

轉自：http://www.iteye.com/topic/1113331

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的消息中间件的实现方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。