网站开通银行支付接口新媒体代运营
🔄 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