Kafka：高可用、顺序消费及幂等性

Kafka

今日小编为你讲解KafkaIT技巧方面的经验，继续往下看吧！

在Kafka这艘数据游轮载着数据航行时，我们这些开发者——也就是船上的水手来说，Kafka集群的高可用性、消息消费的一致性和延时队列等都是确保数据航行安全的关键特性。

所以，拿起你的望远镜，让我们来一探 Kafka 高级知识的奥秘吧！

1.1 背景

说到 Kafka，许多人第一反应可能是：噢，一个消息中间件？

是的，但它远不止如此。Kafka 的力量在于它的可伸缩性、可靠性以及高吞吐。

很多在业务中使用过 Kafka 的小伙伴肯定知道，搭建起一个高效的 Kafka 集群，就像在你的航船上装备强大的引擎。

而恰当地处理消息的重复消费与延时，则犹如在粗犷的海浪中找到了平稳的航道。

坚不可摧的集群舰队：Kafka 高可用

在高海拔时，Kafka 能够展现它的“高”——高可用。

集群化部署后，即便是有节点失联，系统也能自我修复。如同海中的舰队，一艘舰船的失事并不意味着整个航线的中断。

精确把握所有货物：消费去重

重复消费在消息队列中犹如误投递包裹。

在 Kafka 的运送数据时，要确保每条消息只被消费一次，我们得有高超的“航海术”——幂等性与事务。

总有延时的风浪：延时队列处理

和海底的珍珠一样，每个船上的数据包都有其“价值”，然而在时间的尺度上，它们的价值是变化的。

所有才有诗人说：人生遇到的每个人，出场顺序真的很重要！这在消息中间件里也同样适用。

人生没有时光机，但 Kafka 的延时队列有：它不仅可以发送实时消息，还能处理那些需要“重复呈现”的信息。

2. 乘风破浪的Kafka

接下来，让我们更深入地探索这艘快船的强大之处，以及如何利用它。首先，我们搭建一个 Kafka 集群。

2.1 创建三个broker

我们启动了三个容器，配置都略微不同——记住，每艘船都有其独特的身份（broker.id）和自己的泊位（listeners）。

通过进入 Zookeeper 的客户端检查 Kafka 的状态，就如同站在灯塔上检查舰队——确保每艘船都已就绪并在正确的位置。

启动三个容器，server.properties 文件分别为：

# 1,2,3
broker.id = 3
# 49092，49093,49094
listeners=PLAINTEXT://172.16.30.34:49094

校验是否启动成功，进入 zookeeper，查看：

# 进入客户端
./bin/zkCli.sh
# 查看broker
ls /brokers/ids

可以看到各自的 ID 都不同，说明 3 个节点启动成功了：

2.2 集群中的副本

有备无患，副本就好比是同型船的兄弟，一旦领军的船只（leader）遇难，它们（follower）中的一员就会站出来，扛起大旗。

Kafka 的读写操作都发生在 leader 上，leader 还负责把数据同步给 foller。

当 leader 挂了，经过主从选举，从 follower 中选出一个新的 leader。

在这里，Kafka 的调度能力展露无遗。

2.3 关于集群消费

就像团队合作的捕鱼作业，一个 message 可能会被多个消费者（在不同的船上）处理，但恰到好处的通信保证了鱼群的精确分配。

在集群中，我们可以借助以下命令来发送、消费消息：

# 向集群发送消息
./kafka-console-producer.sh --broker-list 172.16.30.34:49092,172.16.30.34:49093,172.16.30.34:49094 --topic my-replicated-topic
# 消费集群消息
./kafka-console-consumer.sh --bootstrap-server 172.16.30.34:49092,172.16.30.34:49093,172.16.30.34:49094 --topic my-replicated-topic
# 指定消费组消费集群消息
./kafka-console-consumer.sh --bootstrap-server 172.16.30.34:49092,172.16.30.34:49093,172.16.30.34:49094 --from-beginning --consumer-property group.id=testGroup1 --topic my-replicated-topic

可以看到，消息发送成功了：

消息消费成功：

3. kafka 集群中的关键角色

3.1 controller

控制器如船队的指挥官，遇见有需要改变的情况时能及时做出应答，无论是船只的增减，抑或是航线的变更。

每个 broker 在启动时会向 zk 创建一个临时序号节点【比如上面创建的broker节点 1,2,3】，获得的最小序号 broker 会作为集群中的 controller，负责以下几件事：

• 当集群中有一个副本的 leader 挂掉，需要在集群中选举出一个新的 leader，选举的规则是从 ISR 集合的最左边元素获取（比如 ISR 集合为 【2,1,3】，当 leader 为 2 并且挂了时，ISR 为 【1,3】，就将 broker-1 上的副本作为新的 leader）；
• 当集群中的 broker 新增或减少时，controller 会同步信息给其他 broker；
• 当集群中有分区新增或减少时，controller 会同步信息给其他 broker。

3.2 rebalance 机制

每一个水手都有其特定的岗位，如同 Kafka 在消费者与分区间实现的再平衡——这是一种资源优化的艺术，和分配负载均衡的请求类似。

在 Kafka 中，再平衡需要一个前提就是：消费组中的消费者没有指定分区来消费。如果对消息指定了分区，rebalance 就不会生效。

并且，当消费组中的消费组和分区关系发生变化时，rebalance 才会触发。这时，消息的分区会遵循以下几个策略中的一种（可配置）：

• range：根据公式计算得到每个消费者去消费哪个分区，前面的消费者分区 = 分区总数/消费者数量+1，后面的消费者 = 分区总数/消费者数量；
• 轮询：几个消费者轮流消费分区；
• sticky：粘合策略，当需要 rebalance 时，会在之前已经分配的基础上调整，且不会改变之前的分配情况。如果这个策略未打开，则需要重新进行全部分区的分配。

3.3 HW 和 LEO