訊息中介軟體的實現方案

2021-09-22 11:18:27 字數 1676 閱讀 1628

訊息中介軟體對目前大中型網際網路來說是非常重要的,在業務資料流動中僅次於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 訊息佇列,傳送者,接受者...

訊息中介軟體

如何理解訊息中介軟體?訊息中介軟體是儲存訊息的乙個容器,與資料庫不同的是資料庫儲存的資料是可以被修改的,而訊息中介軟體一般不會被修改 訊息中介軟體在消費的生產者與消費者產生,相當於乙個中間人的角色,提供了路由保證訊息的傳遞,如果消費者不能及時接收,訊息會保留下來,知道消費者上線 保證在存活期內 訊息...