RocketMQ高可用分析
1、集羣
NameServer集羣
爲無狀態集羣
broker集羣
1）多master模式
2）多master和多slave（異步）
3）多master和多slave（同步）
2、主從複製方式
1）、同步複製
消息從Master複製到Slave後纔給客戶端發送ACK，表示寫成功
安全可靠，如果Master出故障，Slave有全部備份數據，容易恢復。但是會降低吞吐量。
2）、異步複製
消息只要在Master上寫成功後就會給客戶端發送ACK。
不可靠，會造成消息丟失，如果Master出故障，則會造成部分數據丟失。但是響應快，低延時，搞吞吐量
實際應用中藥結合業務場景，合理組合刷盤方式和主從賦值方式。同步刷盤，由於會頻繁觸發磁盤寫動作，會明顯降低性能。通常情況下刷盤方式選擇異步。然後主從賦值方式選擇同步。即使有一臺機器出故障，保證數據不丟失。
3、負載均衡
1）Producer負載均衡
Producer端，每個實例發送消息的時候，默認會輪詢所有的Message queue發送，已達到讓消息平均落到不同的queue上。而由於queue可以散落在不同的broker上，所有消息就發送到不同的broker上，從而達到負載均衡的效果
2）Consumer負載均衡
集羣模式
在集羣模式下，每個消息只需要投遞到訂閱這個topic的Consumer Group下的一個實例即可。MQ主動拉取並消費消息，在拉取的時候需要明確指定拉取哪一條Message queue。
而每當實例的數量發生變化，都會觸發一次Rebalance，安照queue的數量和實例的數量平均分配queue給每個實例。
默認方式：AllocateMessageQueueAveragely
注意：
1、集羣模式下，queue只允許分配給一個實例，如果允許多個實例同時消費同一個queue的消息，由於拉取哪些消息去消費是consumer主動控制的，就會導致同一個消息被不同的實例下消費多次。
2、如果consumer實例數量大於queue的數量，將會出現閒置實例。所以要控制實例的數量要小於等於queue的數量
3、啓動多個消費者，就會負載消費消息，可以水平擴展，每次增加或者減少實例數量，都會觸發負載均衡，原來被分配到的queue將會被分配到其他實例上繼續消費
廣播模式
廣播模式下要求一條消息需要投遞到一個消費組下的所有消費者實例，所以沒有消息被分攤的說法。在事實上，其中一個不同就在consumer分配queue的時候，所有的consumer都分配到所有的queue。
4、消息重試
順序消息的重試
對於順序消息，當消費者消費失敗後，RocketMq會自動不斷進行消息重試（每隔1秒）。這時如果不去處理消費失敗的情況，將會造成消息消費被阻塞。因爲消息是順序的，後面的消費者都在等待前面的消費者成功消費消息。所以務必要及時監控並處理消費失敗的情況。
無序消息的重試
對於無序消息（普通、定時、延遲、事務消息），當消費消息失敗後。可以設置返回狀態，達到重試的效果。無序消息的重試只針對集羣消費方式。對於廣播方式不提供重試特性，當消費失敗後，也不進行重試，繼續消費新的消息。
默認允許每條消息最多重試16次，具體時間間隔如下表
配置方式
1）消息失敗後，重試配置的方式
//1、方式一
return Action.RecomsumeLater;
//2、方式二
return null;
//3、方式三
throw new RuntimeException("Consumer Message Exception");
2）消費失敗，不重試配置方式
return Action.CommitMessage;
允許對重試次數進行自定義，如設置次數超過16次，則每次重試間隔時間爲2小時。
Properties properties = new Properties();
properties.put(PropertyKeyConst.MaxReconsumeTimes,"20");
Consumer consumer = ONSFactory.createConsumer(properties);
注意：
1、如自定義了重試次數，將會對相同Group下的所有consumer實例都生效。
2、如果相同Group下的Consumer都設置了重試次數，則以最後啓動的Consumer實例爲準，會覆蓋之前實例的配置。
5、死信隊列
如果一個消息被重試的次數超過了最大重試次數，最終會被放到死信隊列
有效期與正常消息相同，都是3天。三天後會被自動刪除。
死信隊列有如下特徵：
1、一個死信隊列對應一個Group ID,而不是消費者實例。
2、如果Group ID 未產生死信消息，RocketMQ也不會創建死信隊列。
3、一個死信隊列包含了對應Group ID 產生的所有死信消息，不論該消息屬於哪個Topic。
6、消息的冪等性
同一個消息不管消費了多少次，結果是一樣
重複消息產生
1）發送時消息重複
生產者給MQ發送消息後，由於網絡抖動，投遞給MQ的消息後，MQ沒有及時發ACK給生產者，導致超時，生產者再次發送消息
投遞時消息重複
2）消費方處理了MQ的消息後，在發送ACK給MQ前，出現了網絡閃斷，MQ在網絡恢復後再次嘗試投遞之前的消息。
3）負載均衡時消息重複
當某個broker宕機後重啓、擴容或縮容時，會觸發Rebalance，此時消費者可能收到重複的消息
處理消息重複消費
處理方式
不建議通過messageID進行冪等處理，因爲messageID可能重複。所以真正安全的冪等處理，最好使用以業務唯一標識作爲冪等處理的關鍵依據。而業務的唯一標識可以通過消息key進行設置。