# 生產者
1. 生產者重試，rocketMQ 服務端支援冪等嗎？
2. 生產者兩種傳送方式。
非同步傳送：呼叫執行緒不會阻塞，但呼叫結果會透過回撥的形式，以異常事件或者成功事件返回。
同步傳送：呼叫執行緒阻塞等待傳送結果。
3. 生產者傳送的訊息結構。
主題：topic。
標籤：訊息的標籤，用於進一步分類訊息，支援在消費時進行標籤過濾。
唯一鍵：業務標識，用於冪等、方便查詢和追蹤。
訊息體：業務資料。
使用者自定義屬性：一個鍵值資料結構。
4. 生產者傳送訊息到 broker 的3種ack級別。由低到高，可靠性增強，但是吞吐量降低。
不等待服務端 broker 確認。
等待服務端 master broker 確認。
等待服務端 master broker 和 slave broker 都確認。
# 服務端
5. broker 的刷盤機制
同步刷盤：只有當訊息被成功寫入磁碟後，Broker 才返回確認給生產者（確保訊息持久化）。
非同步刷盤：訊息首先寫入記憶體，然後非同步寫入磁碟（效能高但有資料丟失的風險）。
6. broker 與 topic 的關係。
Topic 是訊息的邏輯分組單位。
Broker是負責儲存、傳遞和查詢訊息的伺服器。一個 RocketMQ 叢集由多個 Broker 組成，每個 Broker 又可以劃分為主（Master）和從（Slave）。
一個 Topic 的佇列可以分佈在不同的 Broker 上，用來實現高可用性和負載均衡。
# 消費者
7. 消費者消費訊息有兩種模式：
拉取：消費者主動從 broker 拉訊息。
優勢：流量控制：消費者可以精確控制訊息的拉取和處理速率，避免過載。
劣勢：有一定延遲。
推送：broker 推送訊息到 consumer。
優勢：低延遲。
劣勢：容易造成 consumer 過載。
8. 如果有個訊息一直消費失敗，會影響後續的訊息消費嗎？
一般情況下不會，因為會發回重試佇列。但是發回重試佇列失敗，會影響後續訊息消費。
9. 重試訊息有單獨的佇列嗎
有。
10. 消費者超時是誰來控制的。
消費者自己來控制的。
11. rebalance 觸發時機：
消費者數量變更 或者 佇列數量變更。具體來說：
消費者週期性地向 Broker 發起心跳請求，並獲取當前消費者組內所有活動消費者，如果消費者數量變更，則 rebalance。
消費者會定期查詢 NameServer 以獲取主題的最新路由資訊，從而知道該主題的訊息佇列的變化情況。如果佇列數量變更，則 rebalance。
12. rebalance 是哪個角色負責的？
消費者。
13. rebalance 具體流程：
檢測到變化 -> 獲取最新消費者列表 -> 獲取最新佇列列表 -> 重新分配訊息佇列 -> 更新本地消費狀態。
# 總結
14. 丟訊息的原因
生產者傳送訊息到 broker 階段，採取低階別的 ack 策略，訊息未同步到 slave broker，同時 master broker 崩潰。
broker 採取非同步刷盤機制。訊息未儲存到磁碟，broker 崩潰。
生產者端業務邏輯寫的有問題。比如傳送訊息後，不處理超時異常、錯誤處理。
15. 重複消費訊息的原因
只要消費者拉取後，沒有向 broker 提交位移，就會重複消費。比如：
消費者重啟。
網路等原因，傳送 ack 失敗。
消費者處理較慢，超過了設定的最大超時時間。
rebalance。消費者在 Rebalance 前處理了部分訊息，但未及時向 Broker 提交消費進度。Rebalance 後，新的消費者可能從上次提交的進度位置開始消費，導致已經處理的訊息被重複消費。
生產者重複傳送訊息。比如第一次傳送訊息超時，會重試傳送。