🔄 Kafka 副本機制（Replication）
核心概念
| 概念 | 說明 |
|---|---|
| Replica (副本) | 分區的完整拷貝，分布在不同 Broker |
| Replication Factor | 副本總數（含 Leader），生產環境建議 ≥3 |
| Leader Replica | 處理所有讀寫請求，負責數據同步 |
| Follower Replica | 被動從 Leader 拉取數據，不服務客戶端請求 |
| ISR | In-Sync Replicas（同步副本集），與 Leader 數據延遲 ≤ replica.lag.time.max.ms |
副本工作流程
寫入過程（生產者視角）
容錯機制（Leader 故障時）
- Controller 檢測 Leader 失效
- 從 ISR 中選舉新 Leader
- 更新集群元數據
- 客戶端重定向到新 Leader
關鍵配置參數
| 參數 | 默認值 | 說明 |
|---|---|---|
replication.factor | 1 | 副本總數（生產環境 ≥3） |
min.insync.replicas | 1 | 寫入成功所需的最少 ISR 副本數（推薦 = replication.factor-1） |
acks | 1 | 生產者確認級別： ? 0：不等待? 1：僅 Leader 確認? all：所有 ISR 確認 |
unclean.leader.election.enable | false | 是否允許非 ISR 副本當選 Leader（生產環境必須關閉） |
replica.lag.time.max.ms | 30000 (30s) | Follower 最大允許滯后時間 |
副本機制價值
? 高可用性：Leader 故障秒級切換
? 數據持久性：多副本冗余防數據丟失
? 讀寫分離：Follower 可處理只讀請求（需特殊配置）
?? CAP 權衡：通過 acks 和 min.insync.replicas 平衡一致性與可用性
📊 分區與副本協同工作示例
如下：kafka集群有三臺服務器，某個主題有2個分區和3個副本（一個Leader，兩個Follower）
設計黃金法則：
分區數決定并行度上限，副本數決定容災能力。
生產環境推薦：分區數 = 消費者數量 × 1.5，副本數 ≥ 3，min.insync.replicas=2
參考：deepseek
