大型分布式架構裡一定會涉及到訊息中介軟體，今天先談談訊息中介軟體。
常用的訊息佇列有activemq，rabbitmq，zeromq，kafka，metamq，rocketmq。
一、kafka
1、不完全符合jms規範，注重吞吐量，類似udp 和 tcp
2、一般做大資料吞吐的管道 我們現在的用途就是負責在各個idc之間通訊
3、量大對資料不是百分之百保證的，會有資料丟失，不是百分百送達（amq和rmq等有重發機制，而kafka沒有）；在吞吐量有提公升 ，在這方面就得有犧牲， 所以kafka適合大資料量流轉， 比如日誌資料 比如用作統計的資料。
二、activemq
activemq居於兩者之間，類似於zemomq，它可以部署於**模式和p2p模式。類似於rabbitmq，它易於實現高階場景，而且只需付出低消耗。它被譽為訊息中介軟體的「瑞士軍刀」。
三：rocketmq（阿里官方指定訊息中介軟體）
訊息中介軟體使用的典型場景優四個
1.典型的非同步處理
2.應用解耦
3.流量削鋒
4.訊息通訊四個場景
比如：今日頭條的私信就是乙個典型的訊息通訊場景，因為訊息通訊的資料不需要即使立即同步回來，不算是核心資料，可以延時通過非同步的訊息傳送，這樣可以降低系統的負荷。
所以，我們在架構設計的時候，有乙個原則就是：訊息原則上都是非同步訊息傳送，除非涉及到交易的情況才考慮資料即使同步，否則能非同步的都採用非同步訊息設計。
再比如：流量削鋒的典型場景就有阿里的雙11秒殺、**搶購活動等。
應用場景：秒殺活動，一般會因為流量過大，導致流量暴增，應用掛掉。為解決這個問題，一般需要在應用前端加入訊息佇列。
a、可以控制活動的人數
b、可以緩解短時間內高流量壓垮應用
使用者的請求，伺服器接收後，首先寫入訊息佇列。假如訊息佇列長度超過最大數量，則直接拋棄使用者請求或跳轉到錯誤頁面。
秒殺業務根據訊息佇列中的請求資訊，再做後續處理。
架構設計之中介軟體總結：
1.訊息中介軟體的四個典型場景：典型的非同步處理、應用解耦、流量削鋒、訊息通訊四個場景。
2.能非同步就不要同步：能非同步的訊息原則都盡量採用非同步的方式。
3.如果訊息效能要求高，用rocketmq與kafka可以更優，rocketmq與kafka 比較就看技術選型了，各有利弊，看業務需要。
4.實現語言來看，rabbitmq(阿里官方指定訊息中介軟體)最高，原因是它的實現語言是天生具備高併發高可用的erlang語言。綜合來看，rabbitmq是首選。
5.典型的秒殺活動、搶購、訊息通訊、郵件傳送、**簡訊等都是典型的採用訊息中介軟體的業務場景。
訊息中介軟體 使用場景
訊息佇列在實際應用中包括如下四個場景 具體場景 使用者使用qq相簿上傳一張，人臉識別系統會對該進行人臉識別，一般的做法是，伺服器接收到後，上傳系統立即呼叫人臉識別系統，呼叫完成後再返回成功，如下圖所示 該方法有如下缺點 人臉識別系統被調失敗，導致上傳失敗 延遲高，需要人臉識別系統處理完成後，再返回給...
訊息中介軟體的使用場景
一般認為，採用訊息傳送機制 訊息佇列 的中介軟體技術，進行資料交流，用在分布式系統的整合。解決分布式系統之間訊息的傳遞。電商場景 使用者下單減庫存，呼叫物流系統，系統擴充後服務化和業務拆分。系統互動，y一般用rpc 遠端過程呼叫 如果系統擴充到有幾十個介面，訊息中介軟體來解決問題。一 非同步處理 使...
訊息中介軟體應用場景
訊息佇列中介軟體是分布式系統中重要的元件，主要實現非同步訊息，應用解耦，流量削峰及訊息通訊等功能。下面舉例說明在實際應用中訊息佇列是如何使用的。以使用者註冊，並且需要註冊郵件和簡訊為例。使用者註冊後，需要傳送註冊郵件和註冊簡訊。傳統的做法有兩種 序列和並行方式。如下圖所示 1 序列方式 將註冊資訊寫...