基础

Kafka 冗余备份的单元是 topic partition.
在非故障情况下，Kafka 中的每个 partition 都对应有单一的 leader 与零个或多个 followers.
所有读和写操作都会转给该分区的 leader, 而 leader 通常均匀的分布在 brokers 之间.
分区的 followers 与 leader 的 offsets & messages 保持着一致, 当然, 除了 leader 上末尾的一些 unreplicated 到其他 followers 上的 messages.

ISR (in-sync replicas)

分区的 followers 会从 leader 拉取 messages 写入到自己的日志文件中,
Kafka 中定义 followers 是否 in sync 有两个条件,

1) 和 ZooKeeper 保持着 session.
2) followers 落后 leader 不是太多.
leader 维护着 in sync 的 followers 列表 (in-sync replicas), 当有 follower 落后 or 崩溃 or 阻塞时,
leader 会将其从 in-sync replicas 列表中移除, 这个延迟的数值是由 replica.lag.time.max.ms 参数控制.
当该分区对应的所有 in-sync replicas 已经把一条消息同步写入到自己的日志中时,
该消息会被认为 committed, 而只有 committed 的消息会被提供给 consumers.
Producers 可以选择等待消息是否已经 committed, 根据自己的业务场景, 可以通过 acks 的设置来控制.

当 leader alive 时, 我们不需要 followers. 然而当 leader dies, 我们就需要从 followers 中选出一个 leader.
此时, 我们理所当然地会选择一个最接近 leader 的 follower.
Kafka 没有采用 majority vote 算法, majority vote 的一个缺点是不多的失败就会让你没有 leader 可用.
如果需要容忍1个错误, 则需要3个 copies. 如果需要容忍2个错误, 则需要5个 copies.
这样对于大容量数据问题来说是不实际的, 这也是为什么 quorum algorithms 主要用于
分享集群配置等数据(比如Zookeeper), 而不是基础数据了.
和 Kafka 实现最相似的算法应该是 Microsoft 的 PacificA.
Kafka 采用了一种稍微不同的方法来选择自己的 quorum 集合,
Kafka 动态维护了一组追得上 leader 的 in-sync replicas (ISR),
这替代了 majority 集合. 只有在 ISR 集合中的成员才有资格被选举成 leader.
一个写操作也只有被 ISR 成员都接收到了, 才能被认为是 committed.
ISR 集合列表被储存在 ZooKeeper 中, 假设有 f+1 个 replicas,
那么能够容忍 f 个故障而不丢失 committed messages.

如果很不幸, ISR 集合中的 replicas 都 die 了, 在可用性和一致性之间,
默认 Kafka 可能会让其他不一致的 replica 被选为 leader,
不过这是可以被修改的, 如果你认为一致性比可用性更重要, 可以通过设置 unclean.leader.election.enable 来禁用.

一个 Kafka 集群有成百上千的 topic partitions, 因此需要
平均分布和避免大量数据聚集在少数结点, 同样也包括 leader 在集群中的平衡.
leader election process 是发生不可用的时候的关键窗口, 因此 Kafka 在 brokers 中选了一个作为 controller,
controller 会检测 brokers 的失败, 并负责修改出问题的 broker 上受影响的 partitions 的 leader.
这样的 batch 操作, 可以在大量的 partitions 场景下更低成本和更快速度的完成 leader election process.
如果 controller 宕机了, 那么其他存活的 brokers 中的一个会成为新的 controller.