始于足|

MuXinu

园龄:2年7个月粉丝:3关注:1

kafka同步机制

Kafka 的同步机制(Replication & Synchronization)

Kafka 通过副本同步机制(Replication & Synchronization)来保证数据的高可用性和可靠性。Kafka 的同步机制主要涉及以下几个核心概念:

1. 副本(Replication)

Kafka 的每个 Partition(分区) 都会有多个副本(Replica),分为:

  • Leader 副本:负责处理生产者和消费者的所有请求。
  • Follower 副本:仅从 Leader 同步数据,不直接处理请求。

副本数由 replication.factor 参数配置。例如:

replication.factor=3  # 每个分区 3 个副本

2. 副本同步(Replica Synchronization)

Kafka 采用同步副本集(ISR, In-Sync Replica) 机制:

  • ISR(同步副本集):Leader 和已同步的 Follower 副本组成的集合。
  • OSR(滞后副本集):落后较多,未能及时同步数据的 Follower。
  • AR(所有副本集):包括 Leader 和所有 Follower。

当 Follower 副本能在 replica.lag.time.max.ms 时间内跟上 Leader,它就会被视为 ISR 成员。

💡 示例:3 副本的 ISR 状态

Partition-0:
   Leader  -> Broker 1
   Follower -> Broker 2 (ISR)
   Follower -> Broker 3 (ISR)

如果 Broker 2 落后太多,它会被踢出 ISR:

Partition-0:
   Leader  -> Broker 1
   Follower -> Broker 3 (ISR)
   Follower -> Broker 2 (OSR, 数据滞后)

3. 数据同步流程

Kafka 采用Leader-Follower 复制模型,Follower 通过 pull(拉取) 的方式从 Leader 获取数据:

  1. Producer 发送消息到 Leader
  2. Leader 将数据写入本地日志
  3. ISR 中的 Follower 轮询拉取数据
  4. Follower 将数据写入本地日志,并向 Leader 发送 ACK
  5. Leader 收到所有 ISR 的 ACK 后,提交数据(commit)

4. 最小同步副本(min.insync.replicas)

为了提高数据安全性,可以设置 min.insync.replicas,要求至少 N 个 ISR 副本 收到数据后,Leader 才能确认消息:

min.insync.replicas=2

如果 ISR 低于 min.insync.replicas,Leader 拒绝写入,防止数据丢失。

示例:

  • replication.factor=3
  • min.insync.replicas=2

情况 1️⃣:两个 Follower 都同步成功

Producer -> Leader -> Follower1, Follower2  ✅(写入成功)

情况 2️⃣:一个 Follower 同步失败

Producer -> Leader -> Follower1 (ISR) 🚫(写入失败,不满足 min.insync.replicas)

5. Leader 选举机制

当 Leader 崩溃时,Kafka 需要选举新的 Leader:

  1. 优先选择 ISR 副本(保证数据一致性)。
  2. 如果没有 ISR 副本(仅 OSR),是否选举 OSR 取决于 unclean.leader.election.enable
    • false(默认):不选 OSR,防止数据丢失(但可能无法选出 Leader)。
    • true:允许 OSR 选举(可能数据不一致)。

示例配置:

unclean.leader.election.enable=false  # 禁止不完全同步的副本成为 Leader

6. 复制延迟(Replica Lag)

Kafka 允许一定的副本同步延迟(Replica Lag),但超出 replica.lag.time.max.ms,Follower 会被踢出 ISR:

replica.lag.time.max.ms=10000  # 超过 10s 未同步,踢出 ISR
  • ISR 过小 → 影响可用性(Leader 崩溃后无可选副本)。
  • ISR 过大 → 影响性能(Follower 过慢)。

7. 事务复制(Transactional Replication)

Kafka 2.0+ 支持 事务复制(Exactly-Once 语义,EOS):

  • 生产者使用 事务 ID(transactional.id) 绑定多个分区的事务。
  • Kafka 通过 read_committed 确保消费者只能消费提交的数据

生产者事务示例:

props.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, "tx-id-123"); // 事务 ID
producer.initTransactions();

try {
    producer.beginTransaction();
    producer.send(new ProducerRecord<>("topic", "key", "value"));
    producer.commitTransaction(); // 提交事务
} catch (Exception e) {
    producer.abortTransaction(); // 回滚事务
}

🔹 总结

机制 作用
副本(Replication) 通过 replication.factor 维护多个副本,提高容灾能力
同步副本集(ISR) 维护与 Leader 同步的副本,保证数据一致性
Follower 拉取数据 采用 pull 模型,避免 Leader 负载过高
最小同步副本(min.insync.replicas) 控制至少多少个 ISR 副本同步后,Leader 才确认写入
Leader 选举 发生故障时,优先选择 ISR 副本作为新的 Leader
副本滞后检测 超过 replica.lag.time.max.ms,Follower 被踢出 ISR
事务复制 通过 transactional.id 实现 Exactly-Once 语义

💡 **Kafka 通过 ISR、最小副本数、事务等机制,保证数据一致性、可靠性和高可用性。

本文作者:MuXinu

本文链接:https://www.cnblogs.com/MuXinu/p/18711905

版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。

posted @   MuXinu  阅读(11)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· DeepSeek 开源周回顾「GitHub 热点速览」
· 记一次.NET内存居高不下排查解决与启示
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· .NET10 - 预览版1新功能体验(一)
点击右上角即可分享
微信分享提示
评论
收藏
关注
推荐
深色
回顶
收起