訊息中介軟體對目前大中型網際網路來說是非常重要的，在業務資料流動中僅次於rpc服務呼叫，擔負著越來越複雜的**業務從主流程上解耦的重要責任；
從目前網際網路對訊息中介軟體的需求來看應該分為兩種型別，一種是和錢相關的需求，一種是和錢無關的需求；和錢相關的需求訊息的可靠性是放在第一位的，和錢無關的需求是速度放在第一位的，但這兩種需求又是矛盾的，很難設計出一種既可靠又高效的系統，除非將兩套方案捏合成乙個系統，通過配置來選擇不同方案，但從實現上說還是兩種實現。所以目前業界有幾種不同的設計方式來滿足不同的需求。
下面看看以下幾種典型實現方案：
1、以activemq為代表的可靠性優先的設計原理：
此種方式將訊息的傳送狀態儲存在客戶端，同時客戶端用拉的模式從訊息伺服器上獲取訊息，由於是順序讀，同時還採取了很多保證速度的策略，如zero-copy，所以此種方案速度比較快，但犧牲了很多可靠性方面的保證，比較適合web2.0**，這些**對訊息的可靠性要求不是很高，同時由於產生了大量的和使用者狀態相關的訊息，需要乙個高效的系統來處理這些訊息；另外這種方案也比較適合日誌訊息的收集；
3、傳統的繫解耦方案：
此種方式是不用訊息中介軟體直接用資料庫儲存做的解耦，隨著訊息中介軟體的出現，這種方式的使用越來越少，但現在由於mongodb和redis等的興起，一些基於這些nosql資料庫的訊息應用逐漸興起，由於訊息資料和訊息狀態都儲存在db上，所以效率和速度在上面兩種方案之間；
那麼有沒有一種更高效的方式呢？
答案是肯定的，但那可能要進一步降低可靠性！
看看facebook的scribe日誌收集系統的原理：
上面的mq暫且叫他fastmq吧，①中訊息發布端直接寫本地檔案，同時訊息訂閱者通過zookeeper協調，向相關訊息發布者的agent拉訊息，並在本地記錄訊息指標狀態；
如果嫌在訊息發布端開啟mq agent麻煩，那麼如②中訊息拉取協議使用scp或ftp協議，用這些linux必備的協議提供者作為agent減少開發和部署的難度，在服務訂閱端解析這些協議流，反序列化為訊息供業務使用；
如果覺得訊息只儲存在訊息發布端的磁碟不可靠，那麼如③中可以在訊息訂閱者處理不及訊息的時候，把訊息資料緩衝在訊息訂閱端的磁碟上來備份資料，不過這樣做就使系統變的複雜，雖然提高了可靠性，但是速度就會有所降低；
此種方案可以使訊息分散的儲存在業務本身的磁碟上，避免集中儲存相互影響的缺點，同時又可以有效利用業務機器的磁碟（大部分業務機器磁碟基本沒使用），另外還可以減少一次網路通訊的過程，使從傳送到接收的速度更快；但其本身也有不少缺點，要做好監控，避免訊息大量積壓的時候業務磁碟過度使用，對業務造成影響。
目前我們的監控日誌收集系統使用的是和②中類似的方案，訊息系統使用的是3方案，後期可能會將可靠性要求高的向1方案過度，可靠性要求不高的向最下面介紹這種過度！
**：
分類:
軟體設計
訊息中介軟體的實現方案
訊息中介軟體對目前大中型網際網路來說是非常重要的，在業務資料流動中僅次於rpc服務呼叫，擔負著越來越複雜的 業務從主流程上解耦的重要責任 從目前網際網路對訊息中介軟體的需求來看應該分為兩種型別，一種是和錢相關的需求，一種是和錢無關的需求 和錢相關的需求訊息的可靠性是放在第一位的，和錢無關的需求是速度...
訊息中介軟體
1.訊息的優先順序 2.訊息排序 3.訊息過濾 4.訊息持久化 5.訊息重試 6.事務的支援 7.broker滿 生產者，佇列，消費者 訊息佇列的優點 1 解耦2 非同步訊息，系統響應 在jms中，有兩種訊息模型 點對點模式和發布訂閱模式。1.在點對點模式中 有三種角色 1 訊息佇列，傳送者，接受者...
訊息中介軟體
如何理解訊息中介軟體？訊息中介軟體是儲存訊息的乙個容器，與資料庫不同的是資料庫儲存的資料是可以被修改的，而訊息中介軟體一般不會被修改 訊息中介軟體在消費的生產者與消費者產生，相當於乙個中間人的角色，提供了路由保證訊息的傳遞，如果消費者不能及時接收，訊息會保留下來，知道消費者上線 保證在存活期內 訊息...