Kafka topic中的partition的Leader选举、ISR副本集合

关于 Partition 的分配，还有 Leader 的选举，总得有个执行者。在 Kafka 中，这个执行者就叫 Controller。Kafka 使用 zookeeper 在 Broker 中选出一个 Controller，用于 Partition 分配和 Leader 选举。（生产过程中 Broker 要分配 Partition，消费过程这里，也要分配 Partition 给消费者。类似 Broker 中选了一个 Controller 出来，消费也要从 Broker 中选一个 Coordinator，用于分配 Partition。）

Leader容灾

Controller 会在 ZK 的 /brokers/ids 节点上注册 Watch，一旦有 Broker 宕机，它就能知道。当 Broker 宕机后，Controller 就会给受到影响的 Partition 选出新 Leader。

Controller 从 ZK 的 /brokers/topics/[topic]/partitions/[partition]/state 中，读取对应 Partition 的 ISR（in-sync replica 已同步的副本）列表，选一个出来做 Leader。选出 Leader后，更新ZK，然后发送 LeaderAndISRRequest 给受影响的 Broker，让它们知道改变这事。

为什么这里不是使用 ZK 通知，而是直接给 Broker 发送 RPC 请求，我的理解是这样的：可能是这样做 ZK 有性能问题吧。如果 ISR 列表是空，那么会根据配置，随便选一个 Replica 做 Leader，或者干脆这个 Partition 就是歇菜；如果 ISR 列表的有机器，但是也歇菜了，那么还可以等 ISR 的机器活过来。（详见下文）

Partition 的分配：

• 将所有 Broker（假设共 n 个 Broker）和待分配的 Partition 排序。
• 将第 i 个 Partition 分配到第（i mod n）个 Broker 上 （这个就是 Leader）。
• 将第 i 个 Partition 的第 j 个 Replica 分配到第（(i + j) mode n）个 Broker 上。
• 注意：当一个 Broker 挂掉之后，所有 Leader 在该 Broker 上的 Partition 都会重新选举，选出一个 Leader（选取 Leader 要从 ISR 中选，ISR 列表是持久化在 Zookeeper 中的，只有在 ISR 列表中的副本才有资格参与 leader 选举）。（这里不像分布式文件存储系统那样会自动进行复制保持副本数）

Kafka集群的所有 topic 的 partition 主从选举通过 controller 来完成。controller 会将 Leader 的改变直接通过 RPC 的方式（比 Zookeeper Queue 的方式更高效）通知需为此作出响应的 Broker。同时 controller 也负责增删 Topic 以及 Replica 的重新分配。

ISR 副本集合

Kafka 为了维护分区副本的同步，引入 ISR（In-Sync Replicas）副本集合的概念，ISR 是分区中正在与 leader 副本进行同步的 replica 列表，且必定包含 leader 副本。

ISR 列表是持久化在 Zookeeper 中的，只有在 ISR 列表中的副本才有资格参与 leader 选举。

ISR 列表是动态变化的，并不是所有的分区副本都在 ISR 列表中，哪些副本会被包含在 ISR 列表中呢？副本被包含在 ISR 列表中的条件是由参数 replica.lag.time.max.ms 控制的（官方从0.9版本开始移除了 replica.lag.max.messages 这一判断方式），参数含义是副本同步落后于 leader 的最大时间间隔，默认10s，意思就是说如果某一 follower 副本中的消息比 leader 延时超过10s，就会被从 ISR 中排除。Kafka 之所以这样设计，主要是为了减少消息丢失，只有与 leader 副本进行实时同步的 follower 副本才有资格参与 leader 选举，这里指相对实时。

官方从0.9版本开始移除了 replica.lag.max.messages 这一判断 replica 是否在 ISR 列表中的方式，Configuration parameter replica.lag.max.messages was removed. Partition leaders will no longer consider the number of lagging messages when deciding which replicas are in sync.

链接：https://kafka.apache.org/documentation/

为什么移除呢？

因为这个值很难取，在高峰的时候，数据的条数很容易就会出现落后的情况，而此时就相应的会出现节点不断的进出 ISR 列表。从 ISA 中选出 Leader 后，Follower 会把自己日志中上一个高水位后面的记录去掉，然后去和 Leader 拿新的数据。因为新的 Leader 选出来后，Follower 上面的数据，可能比新 Leader 多，所以要截取。这里高水位的意思，对于 Partition 和 Leader，就是所有 ISR 中都有的最新一条记录。消费者最多只能读到高水位。
从 Leader 的角度来说高水位的更新会延迟一轮，例如写入了一条新消息，ISR 中的 Broker 都 Fetch 到了，但是 ISR 中的 Broker 只有在下一轮的 Fetch 中才能告诉 Leader。也正是由于这个高水位延迟一轮，在一些情况下，Kafka 会出现丢数据和主备数据不一致的情况，0.11 开始，使用 Leader Epoch 来代替高水位。

Unclean leader 选举

既然 ISR 是动态变化的，所以 ISR 列表就有为空的时候，ISR 为空说明 leader 副本也“挂掉”了，此时 Kafka 就要重新选举出新的 leader。但 ISR 为空，怎么进行 leader 选举呢？
Kafka 把不在 ISR 列表中的存活副本称为“非同步副本”，这些副本中的消息远远落后于 leader，如果选举这种副本作为 leader 的话就可能造成数据丢失。Kafka broker 端提供了一个参数 unclean.leader.election.enable，用于控制是否允许非同步副本参与 leader 选举；如果开启，则当 ISR 为空时就会从这些副本中选举新的 leader，这个过程称为 Unclean leader 选举。
前面也提及了，如果开启 Unclean leader 选举，可能会造成数据丢失，但保证了始终有一个 leader 副本对外提供服务；如果禁用 Unclean leader 选举，就会避免数据丢失，但这时分区就会不可用。这就是典型的 CAP 理论，即一个系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）中的两个。所以在这个问题上，Kafka 赋予了我们选择 C 或 A 的权利。
我们可以根据实际的业务场景选择是否开启 Unclean leader选举，这里建议关闭 Unclean leader 选举，因为通常数据的一致性要比可用性重要的多。

副本同步

这里的策略，服务端这边的处理是 Follower 从 Leader 批量拉取数据来同步。但是具体的可靠性，是由生产者来决定的。生产者生产消息的时候，通过 request.required.acks 参数来设置数据的可靠性。

在 Acks=-1 的时候，如果 ISR 少于 min.insync.replicas 指定的数目，那么就会返回不可用。

关于消费

消息消费的时候，首先要知道去哪消费，这就是 路由，消费完之后，要记录消费单哪，就是 Offset