怎樣算是理解了一套MQ中間件呢？原來一知半解的我列了幾個維度：demo跑起來，理解其投遞次數的語義，理解其事務的特性等等。這是一種角度，但總有種看山不是山的一知半解的感覺。再問一層，比如為什么Kafka吞吐量遠勝於其他中間件，為什么說適合日志采集和流式計算的場景？就回答不上來了。學習終歸是個積累的過程。
直到某一天看到阿里一篇挺常規的關於Notify和MetaQ的介紹，卻突然茅塞頓開。當然了，其中不乏是做了一兩個需求的緣故。故事是圍繞着一下幾個疑問展開的。
1.什么是消息中間件，解決了什么問題？Message Queue嘛，顧名思義就是排隊。打個比方去快餐店點餐，每個人點餐可能只要10s，但如果三個人同時向服務員點餐，服務員就可能會亂了，三個顧客還可能會吵起來，這件事就沒法30s內解決，那么很簡單，排隊點餐就好辦了。所以MQ最核心的功能就是削峰蓄洪。其他特征則是圍繞這一功能衍生出來的，比如如何維持排隊的人不亂套（持久化和重發和事務支持），如何容納更多的人排隊（堆積能力），如果實在接待不了這么多人怎樣讓后來的人去其他地方安置（限流機制）等等。
2.MetaQ與Kafka的對比。名字緣由是說Metamorphosis變形記是向卡夫卡致敬。明明Kafka性能遠勝於MetaQ，為什么還要造出個MetaQ呢？因為支持了tag過濾了啊，過濾的特性放在電商系統里對性能的提升比單機的吞吐量和堆積能力還更重要。也就是說，MetaQ加入的是更場景化的特性。
3.MetaQ與ActiveMQ的對比。側重談前者，后者遵循AMQP協議。MetaQ串行化寫盤快（隨機讀可以做內存緩存），pull拉式訂閱解放了broker的路由壓力，邏輯隊列只存索引信息非常輕。這里解決的問題，是性能的問題，持久化時如何寫得快而准、如何讀得快，消息堆積時如何能堆更多，投遞時如何又靈活又快又省資源（cpu和帶寬）。
4.JMS與AMQP。JMS是java接口規范。AMQP是跨越語言的MQ標准，並規划了路由到投遞的分層設計。
5.共性。投遞次數的語義完全是共性，基本都是至少投遞一次的語義，要支持至多投遞一次並不難但是場景很少，要支持准確投遞一次很難且代價太大，何不讓應用自己去做接口冪等。事務則是取舍，能支持事務的都會犧牲一些性能，不支持事務的一般都會更輕快。廣播等其他特性，要看具體的應用場景。
所以，如何深入學習一套MQ中間件？圍繞其持久化的形式（kv或串行寫盤等等）、堆積的能力（隊列的底層數據結構）、投遞方式（push的路由規則或pull的尋址及過濾）就已經是很了解了。再加上個高可用主從模式，就幾乎完全掌握了。