MetaQ是一款分佈式、隊列模型的消息中間件。基於發佈訂閱模式，有Push和Pull兩種消費方式，支持嚴格的消息順序，億級別的堆積能力，支持消息回溯和多個維度的消息查詢。
自己的理解：以前看過Rabbit MQ，所以感覺基本的功能跟這個中間件差不多，但是一些細節上的優化可能會有所不同，接下來的使用中，我想我會發現它們的不同，我會實時來更新博客的，希望讀者和我都會得到提升~~~~~
發佈消息
-
日常環境不需要申請即可發送，Topic與Producer Group請保證唯一即可，但是如果需要在控制檯裏管理，則需要在控制檯裏申請對應的資源。
-
生產環境必須要到MetaQ Console申請才能發送，目前已經升級成自動審批，如有問題再聯繫metaq的開發(公司內部作用，不用看)。
-
對於非常重要的消息，例如訂單消息，業務方需要有重發補償的機制，例如MetaQ服務短暫不可用，此時發往MetaQ的消息將失敗，等到MetaQ服務恢復後，業務方可以將之前發送失敗的消息重新補償發送
-
對於Message Size特別大的消息如何處理？例如1M，幾百K的消息 不推薦應用發送超過16K的消息，如果消息確實比較大，發送消息客戶端有個配置，默認超過4K的消息開始壓縮，消息到達訂閱方之前會自動解壓，壓縮過程對用戶透明，但是如果壓縮過以後消息仍然較大，我們推薦應用對消息進行拆分，這樣做的原因如下
- MetaQ通信層沒有對大的請求做優化，採用的是典型的RPC方式，不適合大的請求傳遞，可能會導致網絡層的Buffer異常。
- MetaQ的服務器存儲是一個典型的LRU CACHE系統，過大的消息會佔用較多Cache，對於其他應用Cache命中率產生影響
- MetaQ的磁盤資源通常比較緊張
- MetaQ暫不解決大消息存儲問題
-
發送消息時，如果將來需要查詢消息，或者定位消息是否被接收，需要設置Message Key屬性，例如設置爲訂單Id，商品Id等
-
發送消息時，如果訂閱方有過濾需求，請在消息Tag屬性上設置相關值，Tag的名稱不需要申請，可自由設置，一條消息只允許設置一個Tag。
-
發送事務消息，出於運維角度考慮，淘寶用戶請使用Notify。
訂閱消息
-
日常、預發等非生產環境，訂閱消息不需要申請。訂閱生產環境的消息，必須要到MetaQ Console申請才能訂閱，系統自動審批。
-
MetaQ支持服務器消息過濾，如果訂閱某個Topic，但只關心其中一部分消息，可以使用表達式方式過濾。這樣可以避免無用的消息傳輸到客戶端，而且降低了應用與MetaQ服務器的負載。過濾表達式中的Message Tag是由發送方自由指定，MetaQ不做任何限制，當然不能傳入非法字符，例如空白字符、|| 等
-
非順序消息消費，耗時時間不做限制，但是應用應該儘可能保證耗時短，這樣才能達到高性能，另外消費消息Hang住，會導致消息所在隊列的消費動作暫停，直到Hang住的消息消費完。對其他隊列不受影響
-
順序消息消費，耗時時間有限制，要保證每條消息在30s內消費完，超過30s會有潛在的亂序問題。（原因是分佈式鎖超時問題，但概率極低）
消費方式
-
集羣消費，一條消息只會被同一個group裏一個消費端消費。不同group之間相互不影響。
-
廣播消費，一條消息會被同一個group裏每一個消費端消費。
消息重複性
-
MetaQ不能保證消息不重複，"Exactly Only Once"這個特性不支持，原因如下：
- 發送消息階段，會存在分佈式環境下典型的超時問題，即發送消息階段不能保證消息不重複。
- 訂閱消息階段，由於涉及集羣訂閱，多個訂閱者需要Rebalance方式訂閱，在Rebalance短暫不一致情況下，會產生消息重複
- 訂閱者意外宕機，消費進度未及時存儲，也會產生消息重複
-
消息重複性問題如何解決？
- 應用方收到消息後，可通過Tair、DB等去重
- 應用方可通過主動拉的方式，可保證拉消息絕對不重複，但是分佈式協調分配隊列問題需要應用來控制
- 消息中間件團隊也在思考如何有效去重，又對整個消息系統性能影響最低。
廣播消息
-
MetaQ支持廣播消息，但是廣播消息的代價較高，投遞比可能在1:100甚至1:1000，對於生產環境訂閱廣播消息，人工審覈環節可能會拒絕，取決於訂閱的消息量及消費者集羣規模。
-
MetaQ的廣播消息不支持失敗重試，原因如下：
- 對於集羣消費的消息支持失敗重試，因爲失敗的維度是一個訂閱組集羣，而廣播消息失敗重試維護的則是訂閱組集羣中的每個訂閱者，代價較高。
-
MetaQ的廣播消息消費進度維護在消費者本地磁盤，每隔5s刷盤一次，如果本地磁盤損壞，消費進度如何恢復？
- 聯繫MetaQ運維人員，通過運維工具按照時間維度，例如回退一小時，新創建一份消費進度。（此功能開發中）
消息重試
-
非順序消息消費失敗重試，消費失敗的消息發回服務器，應用可以指定這條失敗消息下次到達Consumer的時間。消費失敗重試次數有限制，通常線上爲每個訂閱組每條失敗消息重試5次（每次消息都會定時重試，定時時間隨着重試次數遞增，此過程應用可干預）。超過重試次數，消息進入死信隊列，並向用戶報警。
-
消息重試對於服務器代價較高，如果某個應用消息量非常大，且失敗率非常高，需要大量重試，則不建議使用MetaQ
-
順序消息消費失敗重試，某個隊列正在消費的消息消費失敗，會將當前隊列掛起（掛起時間應用可通過API設置），其他隊列仍然正常消費。
死信隊列
消息一旦進入死信隊列，則不再向應用投遞，MetaQ監控系統會嚮應用報警 （報警功能開發中）
由於消息一旦進入死信隊列，則不能再被訂閱，建議應用在最後一次重試消費時，將失敗消息保存到DB
消息堆積
MetaQ每臺服務器提供大約億級的消息堆積能力（多個業務方共用），超過堆積閥值，訂閱消息吞吐量會下降。
消息實時性
MetaQ採用了長輪詢方式從Broker拉消息，實時性同Push方式一致，消息的延遲時間大約幾毫秒左右。
至於具體的實戰應用，我會在接下來的使用中詳細介紹~~~