流程就不寫了，寫點自己的總結(jié)，希望對各位有用，從解決問題的角度去觀察RocketMq的設(shè)計思路，本人水平有限，說錯的地方請及時指出。
問題一 RocketMq 消費流程
問題二 rocketmq 負載均衡策略有哪些。
獲取topic 對應(yīng)的消費客戶端和所有的broker 下的Que隊列 然后根據(jù)一定的算法分配本客戶端要拉取的QueID
分配算法
? ? ? ? ? ? 1? 環(huán)行平均分配算法，平均然后輪流分配
? ??????? ? ? ? q1 q2 q3 q4 q5 q6 q7 q8 3個消費隊列 c1 c2 c3
? ? ? ? ? ? ? ? c1:q1 q4 q7
? ? ? ? ? ? ? ? c2:q2 q5 q8
? ? ? ? ? ? ? ? c3:q3 q6
? ? ? ? ? ? 2 平均分配?
????????????????q1 q2 q3 q4 q5 q6 q7 q8 3個消費隊列 c1 c2 c3
????????????????c1: q1 q2 q3
????????????????c2: q4 q5 q6
????????????????c3: q7 q8
? ? ? ? ? ? 3機房優(yōu)先平均分配
? ? ? ? ? ? ? ? 優(yōu)先分配同機房的消息隊列，然后平均
? ? ? ? ? ?4自定義算法指定客戶端消費某些隊列算法。
? ? ? ? ? ? 5 一致性hash算法
? ? ? ? ? ? ? ? 算法原理：
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 步驟1 構(gòu)造clientid的hash環(huán),TreeMap 為集合，hash值作為key，節(jié)點為clientid
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 步驟2 計算que的hash 節(jié)點，獲取> 本hash值得最近得一個clientid節(jié)點。
問題三 拉取offset下標(biāo)如何計算
問題四 rocketmq consume客戶端 高并發(fā)體現(xiàn)在哪？
? ? 1 多線程并行處理，不同得隊列并行拉取數(shù)據(jù)，消息并行消費
默認一次拉取32消息，節(jié)省網(wǎng)絡(luò)帶寬
2 并發(fā)消費，不會因為中間得一個消息有問題，就停頓卡進度
? ? 一個個消息消費，根據(jù)結(jié)果 反饋broker，有問題仍然 反饋給服務(wù)端進入重試隊列，進行下一次得消費重試，不會因為有問題導(dǎo)致消費進度得卡頓
?
3 即使有一個消息有問題死循環(huán)，有超時檢測機制
????對待處理得消息隊列進行超時判斷，超過了時間沒處理完畢，發(fā)送回broker ，并從內(nèi)存中移除。
問題五?
rocketmq 消費offset 反饋機制是如何更新得？批量消費中，如下圖所示，消費完是更新坐標(biāo)最小得，還是更新坐標(biāo)做大得，為什么？多線程，單個消費中，后面得先于前面得消費完，坐標(biāo)是更新得是小得，還是大得。？
答案
答案：無論批次消費，還是一個個消費，坐標(biāo)以小得為準(zhǔn)。
目的：防止后面得消費完，前面得消息還沒消費完，服務(wù)宕機了，導(dǎo)致消息丟失。
源碼：
? ??????
存在得問題：為了確保消息不丟失，服務(wù)器重啟得時候，會導(dǎo)致重復(fù)消費。
問題六 順序消費 流程，順序消費和并發(fā)消費有什么不同。
順序消費的目的:客戶端消費消息是按照，消息進入的順序，并發(fā)消息，offset大的消息，有可能先于offset小的消息先行消費完。
1消費邏輯上，順序消費，必須鎖定broker 對應(yīng)的消息隊列，防止重新負載的時候分配給其他client
2順序消費，一次拉取32條消息，如果中間有一條消息卡滯，消費失敗，后面的消息掛起，這條消息重試16次，
如果還是失敗，就會發(fā)回服務(wù)端。跳過此次消費。
問題七
順序消費上了幾把鎖，為什么要上鎖
1 負載均衡的時候，隊列發(fā)生變化
目的：負載變化，要求broker給隊列上鎖，變更期間不允許分配給其他client
2數(shù)據(jù)拉取后，對隊列數(shù)據(jù)的加鎖，保持隊列的順序性消費
對集合上鎖。
問題八rocketmq如何確保消息不丟失？
1 消息重試機制，消費失敗的消息會重新發(fā)回broker端，
2 broker收到ack 響應(yīng)才認為消費成功，否則不認為是成功
3客戶端拉取一批消息，即使后面的先于前面的消費完，即使broker宕機，也只更新低的offset 確保消息不丟失
問題九消息重試，場景有哪些
1消費失敗會發(fā)回重試。根據(jù)重試的次數(shù)， 發(fā)往不同等級的重試隊列
定時取出消息發(fā)往原來的topic 和que
達到最大失敗次數(shù)放入死信隊列
問題十 消息堆積，怎發(fā)現(xiàn)，如何解決
消息堆積有幾種原因
消息堆積監(jiān)控
1.判斷是否存在消息堆積場景
? ? ? ?1producer發(fā)送消息的速率監(jiān)控
? ? ? ?2producer發(fā)送消息的maxOffset與consumer消費消息的currOffset的差異值與給定的消息堆積數(shù)值告警值對比，如果差異? ?值大于數(shù)據(jù)告警值，則存在消息堆積，否則不存在消息堆積。
? ? ? ?3consumer消費消息的速率監(jiān)控
通過擴容能解決問題的現(xiàn)象
? ? ? ? 1 突然流量激增，導(dǎo)致堆積。
? ? ? ? 2? Broker消息堆積，比如Broker的性能瓶頸，Broker同步策略導(dǎo)致消息堆積等
? ? ? ? ?3 consumer本身已經(jīng)拉取消息的堆積。consumer消息拉取超過一定量之后會暫停消息拉取，一方面是消費者本身消費能力的現(xiàn)在，另一方面是由于消費端過多的消息容易造成GC頻繁。
擴容還解決不了的問題，還存在擠壓現(xiàn)象，就要考慮broker 或client本身的故障
? ? ? ??這種情況基本上是可以確定是RocketMQ本身的故障照成的，比如Broker故障，比如Broker的GC頻率過高導(dǎo)致消息推送，copy性能降低，集群內(nèi)部網(wǎng)絡(luò)故障，等等。此時主要是監(jiān)控RocketMQ服務(wù)器性能，或消費邏輯有問題
感謝以下作者辛苦的勞作參考
http://www.itdecent.cn/p/45aa7465dfc1?ProcessQueue處理隊列 作用
https://www.cnblogs.com/chenjunjie12321/p/7922362.html?消費端整體流程
https://my.oschina.net/javamaster/blog/1929879??流量控制
listener.consumeMessage 如果一直死循環(huán)不返回雜辦？Ack卡進度解決方案 http://jaskey.github.io/blog/2017/01/25/rocketmq-consume-offset-management/ rockmq 消費失敗處理 rockmqack 機制具體解析
http://www.luyixian.cn/news_show_36799.aspx 并發(fā)消費和順序消費區(qū)別
http://www.itdecent.cn/p/fcfc662368f4 offset更新流程
并發(fā)消費任務(wù)后續(xù)任務(wù)是如何增加得
https://cloud.tencent.com/developer/article/1521811
?rebalance 解析
https://blog.csdn.net/yuxiuzhiai/article/details/103884106
消息堆積，解決方案?
https://blog.csdn.net/mlydaemon/article/details/105899869
https://blog.csdn.net/luanlouis/article/details/88078657
https://www.infoq.cn/article/NcSYj_2PQhBlqveuD1Kw?
offset游標(biāo)更新方法
https://blog.csdn.net/fei33423/article/details/51255082
并發(fā)消費和順序消費區(qū)別
https://www.cnblogs.com/allenwas3/p/12245217.html
RocketMq重試的場景
https://juejin.im/entry/5c9cf65ae51d453f77070d9b
rocketmq 框架需要解決得問題
https://www.cnblogs.com/yushangzuiyue/p/9684000.html
offset問題刨析
https://juejin.im/post/5d72724cf265da03be48fd24
