10分钟带你逆袭Kafka！( 五 ) _Kafka

文章插图

Zookeeper：Zookeeper 负责维护和协调 Broker，负责 Broker Controller 的选举。在 Kafka 0.9 之前版本，Offset 是由 ZK 负责管理的。总结：ZK 负责 Controller 的选举，Controller 负责 Leader 的选举。
Coordinator：一般指的是运行在每个 Broker 上的 Group Coordinator 进程，用于管理 Consumer Group 中的各个成员，主要用于 Offset 位移管理和 Rebalance 。一个 Coordinator 可以同时管理多个消费者组。【10分钟带你逆袭Kafka！】
Rebalance：当消费者组中的数量发生变化，或者 Topic 中的 Partition 数量发生了变化时，Partition 的所有权会在消费者间转移，即 Partition 会重新分配，这个过程称为再均衡 Rebalance 。
再均衡能够给消费者组及 Broker 带来高性能、高可用性和伸缩，但在再均衡期间消费者是无法读取消息的，即整个 Broker 集群有小一段时间是不可用的。因此要避免不必要的再均衡。

Offset Commit：Consumer 从 Broker 中取一批消息写入 Buffer 进行消费，在规定的时间内消费完消息后，会自动将其消费消息的 Offset 提交给 Broker，以记录下哪些消息是消费过的。当然，若在时限内没有消费完毕，其是不会提交 Offset 的。

Kafka的工作原理和过程

①消息写入算法
消息发送者将消息发送给 Broker, 并形成最终的可供消费者消费的 log，是已给比较复杂的过程：

Producer 先从 Zookeeper 中找到该 Partition 的 Leader 。
Producer将消息发送给该 Leader 。
Leader 将消息接入本地的 log，并通知 ISR 的 Followers 。
ISR 中的 Followers 从 Leader 中 Pull 消息, 写入本地 log 后向 Leader 发送 Ack 。
Leader 收到所有 ISR 中的 Followers 的 Ack 后，增加 HW 并向 Producer 发送 Ack，表示消息写入成功。

②消息路由策略
在通过 API 方式发布消息时，生产者是以 Record 为消息进行发布的。

Record 中包含 Key 与 Value，Value 才是我们真正的消息本身，而 Key 用于路由消息所要存放的 Partition 。

消息要写入到哪个 Partition 并不是随机的，而是有路由策略的：

若指定了 Partition，则直接写入到指定的 Partition 。
若未指定 Partition 但指定了 Key，则通过对 Key 的 Hash 值与 Partition 数量取模，该取模。
结果就是要选出的 Partition 索引。
若 Partition 和 Key 都未指定，则使用轮询算法选出一个 Partition 。

③HW 截断机制
如果 Partition Leader 接收到了新的消息，ISR 中其它 Follower 正在同步过程中，还未同步完毕时 leader 宕机。

此时就需要选举出新的 Leader 。若没有 HW 截断机制，将会导致 Partition 中 Leader 与 Follower 数据的不一致。

当原 Leader 宕机后又恢复时，将其 LEO 回退到其宕机时的 HW，然后再与新的 Leader 进行数据同步，这样就可以保证老 Leader 与新 Leader 中数据一致了，这种机制称为 HW 截断机制。

④消息发送的可靠性
生产者向 Kafka 发送消息时，可以选择需要的可靠性级别。通过 request.required.acks 参数的值进行设置。

0 值：异步发送。生产者向 Kafka 发送消息而不需要 Kafka 反馈成功 Ack 。该方式效率最高，但可靠性最低。

其可能会存在消息丢失的情况：

在传输过程中会出现消息丢失。
在 Broker 内部会出现消息丢失。
会出现写入到 Kafka 中的消息的顺序与生产顺序不一致的情况。

1 值：同步发送。生产者发送消息给 Kafka，Broker 的 Partition Leader 在收到消息后马上发送成功 Ack（无需等等 ISR 中的 Follower 同步）。

生产者收到后知道消息发送成功，然后会再发送消息。如果一直未收到 Kafka 的 Ack，则生产者会认为消息发送失败，会重发消息。

该方式对于 Producer 来说，若没有收到 Ack，一定可以确认消息发送失败了，然后可以重发。

但是，即使收到了 ACK，也不能保证消息一定就发送成功了。故，这种情况，也可能会发生消息丢失的情况。

-1 值：同步发送。生产者发送消息给 Kafka，Kafka 收到消息后要等到 ISR 列表中的所有副本都同步消息完成后，才向生产者发送成功 Ack 。

如果一直未收到 Kafka 的 Ack，则认为消息发送失败，会自动重发消息。该方式会出现消息重复接收的情况。