1.面試的問題
- 要點 至多一次、恰好一次
- 數據一致性
- 超時重試、冪等
- 消息順序
- 消息擠壓
- 延時消息
1.1 kafaka 生產消息的過程。
在消息發送的過程中，涉及到了兩個線程，一個是main 線程，一個是sender 線程。在main 線程中創建了一個雙端隊列 RecordAccumulator，main 線程將消息發送到 雙端隊列，sender 線程不斷從雙端隊列讀取 發送到 broker
1.2 消息隊列的可靠性。
1.3 副本同步機制
leo: 定義：LEO 即日志末端偏移量，它表示每個副本日志中最后一條消息的下一個偏移量。
hw:高水位（HW，High Watermark）的確是 ISR（In - Sync Replicas，同步副本集合）中所有副本的最小日志末端偏移量（LEO，Log End Offset）
Kafka 的副本同步機制
Kafka 的副本同步機制是保障數據可靠性和高可用性的核心特性，下面從整體架構、同步流程、ISR 機制、相關參數等方面進行詳細介紹。
整體架構
- Kafka 中每個分區都有一個 Leader 副本和多個 Follower 副本。生產者和消費者只與 Leader 副本進行交互，Follower 副本負責從 Leader 副本同步數據。這樣的設計使得 Kafka 可以在多個 Broker 上存儲數據副本，提高數據的容錯能力。
同步流程
- 消息生產
生產者將消息發送到 Kafka 集群時，會指定要發送到的主題和分區。Kafka 根據分區的 Leader 副本位置，將消息發送到對應的 Leader 副本所在的 Broker。 - Leader 副本接收消息
Leader 副本接收到生產者發送的消息后，將消息寫入本地日志，并更新自身的日志末端偏移量（LEO）。 - Follower 副本同步消息
Follower 副本通過向 Leader 副本發送 Fetch 請求來同步消息。Fetch 請求中包含 Follower 副本當前的 LEO，Leader 副本根據該信息將新的消息發送給 Follower 副本。
Follower 副本接收到消息后，將消息寫入本地日志，并更新自身的 LEO。 - 高水位（HW）更新
高水位（HW）是分區中所有副本都已經成功復制的消息的最大偏移量。Kafka 會根據 ISR（In - Sync Replicas，同步副本集合）中所有副本的 LEO 來更新 HW。具體來說，HW 是 ISR 中最小的 LEO。
只有偏移量小于 HW 的消息才被認為是已經在所有同步副本中安全保存的，可以被消費者消費。
ISR 機制 - ISR 定義
ISR 是與 Leader 副本保持同步的一組副本集合。只有在 ISR 中的副本，才被認為是可靠的同步副本，能夠參與 HW 的計算。 - ISR 動態維護
Kafka 會定期檢查 Follower 副本與 Leader 副本的同步情況，通過比較 LEO 的差距來判斷 Follower 副本是否落后。如果 Follower 副本的 LEO 與 Leader 副本的 LEO 差距超過一定閾值（由 replica.lag.time.max.ms 參數控制），則該 Follower 副本會被從 ISR 中移除。
當落后的 Follower 副本追上 Leader 副本后，它可以重新加入 ISR。 - ISR 的作用
提高數據可靠性：只有 ISR 中的副本參與 HW 的計算，確保消費者只能讀取到已經在多個副本中安全保存的消息。
故障轉移：當 Leader 副本出現故障時，Kafka 會從 ISR 中選舉出新的 Leader 副本，保證數據的一致性和服務的連續性。
相關參數 - acks 參數
該參數用于控制生產者發送消息時的確認機制，影響副本同步策略。
acks = 0：生產者發送消息后，不等待任何確認，相當于異步復制，性能最高但數據可靠性最低。
acks = 1：生產者發送消息后，等待 Leader 副本確認，只要 Leader 副本寫入成功就返回響應，性能和可靠性適中。
acks = all 或 acks = -1：生產者發送消息后，等待所有 ISR 中的副本確認，相當于同步復制，數據可靠性最高但性能最低。 - min.insync.replicas 參數
用于指定 ISR 中最少需要有多少個副本同步消息，才能認為消息寫入成功。結合 acks = all 使用時，可以進一步增強數據的可靠性。如果 ISR 中的副本數量小于 min.insync.replicas，生產者發送消息時會收到寫入失敗的響應。 - replica.lag.time.max.ms 參數
該參數定義了 Follower 副本與 Leader 副本之間允許的最大延遲時間。如果 Follower 副本在該時間內沒有向 Leader 副本發送 Fetch 請求或者沒有追上 Leader 副本的 LEO，則會被從 ISR 中移除。
異常情況處理 - Leader 副本故障
當 Leader 副本所在的 Broker 出現故障時，Kafka 會從 ISR 中選舉出新的 Leader 副本。新的 Leader 副本會將 HW 作為新的起始偏移量，繼續處理生產者和消費者的請求。 - Follower 副本故障
如果某個 Follower 副本出現故障，它會被從 ISR 中移除。當該副本恢復正常后，會重新向 Leader 副本發送 Fetch 請求，追趕 Leader 副本的進度，當追上后可以重新加入 ISR。
綜上所述，Kafka 的副本同步機制通過 Leader - Follower 架構、ISR 機制和相關參數的配置，在保證數據可靠性和高可用性的同時，兼顧了性能和容錯能力。
1.4 kafka 高性能、高吞吐原因
- 磁盤順序讀寫
- 順序讀 會使用預讀
- 保證了消息的堆積 相比于內存。
- 使用了零拷貝的技術
- 分區分段 + 索引
- 每個 分區 在磁盤上 按照segment 文件存儲的。針對segment 建立.index的索引文件
- 批量壓縮 多條消息批量壓縮傳輸，降低帶寬
- 批量讀寫
1.5 消息丟失的場景 解決方案
- ack=all,
- 配置 min.insync.replicas>1
1.6 消息可靠性的解決方案
消息發送
- ack -1/all 、
- unclean.leader.election.enable: false, 禁止選舉 isr 以外的follower為leader
- tries >1 重試次數
- min.insync.replicas>1 同步副本數，沒滿足該之前，不提供 讀寫服務。
綜上所述，在 acks = all 且 min.insync.replicas = 3，副本總數為 5 個的情況下，至少 3 個處于 ISR 中的副本寫入數據完成，Kafka 才會判定消息寫入操作完成。
消費者
- 手動提交 offset
- broker 減少刷盤間隔
- 事務消息
1.7 kafka reblance
- 消費者分區策略
- range 范圍分區 默認
- roundrobin 輪詢
- sticky 策略 體現在 reblance 策略下。
- 觸發reblance 的時間
- 消費者組成員個數變化的時候。
有新的消費者加入、離開消費者組 - 訂閱的topic 發生變化
- 訂閱topic 的分區發生變化
- coordinator 協調過程
- 消費者 找到消費者組中的 協調器
- 確定分區策略
system design interview 書
第八章 設計短鏈系統
kafka 筆記
尚硅谷-筆記
