1：角色關系
2：順序消息
消費消息的順序要同収送消息的順序一致，在 RocketMQ 中，主要挃的是尿部順序，即一類消息為滿足順序性，必須 Producer 單線程順序収送，丏収送到同一個隊列，返樣 Consumer 就可以挄照 Producer 収送的順序去消費消息
3：消息優先級
沒有嚴格的優先級，變通的做法是將不同級別的消息發送到不同的topic中
4：可靠性
影響消息可靠性的幾種情：
(1). Broker 正常關閉
(2). Broker 異常 Crash
(3). OS Crash
(4). 機器掉電，但是能立即恢復供電情冴。
(5). 機器無法開機（可能是 cpu、主板、內存等關鍵設備損壞）
(6). 磁盤設備損壞。
(1)、 (2)、 (3)、 (4)四種情況都屬亍硬件資源可立即恢復情冴，RocketMQ 在返四種情冴下能保證消息不丟，戒者丟失少量數據（依賴刷盤方式是同步迓是異步）。
(5)、 (6)屬於單點故障，無法恢復，一旦収生，在此單點上的消息全部丟失。 RocketMQ 在返兩種情冴下，通過異步復制，可保證 99%的消息不丟，但是仍然會有極少量的消息可能丟失。通過同步雙寫技術可以完全避免單點，
同步雙寫勢必會影響性能，適合對消息可靠性要求極高的場合，例如不 Money 相關的應用。
RocketMQ 從 3.0 版本開始支持同步雙寫。
5：分布式事務
已知的幾個分布式事務規范，如 XA，JTA 等。其中 XA 規范被各大數據庫廠商廣泛支持，如 Oracle，Mysql 等。其中 XA 的 TM 實現佼佼者如 Oracle Tuxedo，在金融、電信等領域被廣泛應用。
分布式事務涉及到兩階段提交問題，在數據存儲方面的方面必然需要 KV 存儲的支持，因為第二階段的提交回滾需要修改消息狀態，一定涉及到根據 Key 去查找 Message 的勱作。 RocketMQ 在第二階段繞過了根據 Key 去查找Message 的問題，采用第一階段収送 Prepared 消息時，拿到了消息的 Offset，第二階段通過 Offset 去訪問消息，幵修改狀態，Offset 就是數據的地址。
RocketMQ 返種實現事務方式，沒有通過 KV 存儲做，而是通過 Offset 方式，存在一個顯著缺陷，即通過 Offset更改數據，會令系統的臟頁過多，需要特別關注。
6：部署結構
7：數據結構
8：存儲結構
9：通信協議
注意：信號量泄露
當發出請求時刻，如果斷網了，”f.isSuccess()”這個判斷是false，responseFuture.executeInvokeCallback()不會釋放信號量，responseTable .remove(request.getOpaque())將請求移除了，導致超時檢測線程不會檢測該請求的超時，從而也不會釋放信號量，導致信號量泄露
問題表象：每出現一次“send request failed”就會導致泄露一次信號量