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

Kafka

HW（high-weight，高水位）和 LEO（log-end-offset）是衡量副本最后消息位置的两个重要指标，它们就像是船上的测深仪，确保了数据不被过早或不当地处理。

HW 是已完成 lead-follower 同步的位置，消费者无法消费到 HW 线之前的消息。并且，在完成同步以后，HW 线才更新，以防止消息丢失。

LEO 是指某个副本最后消费消息的位置，根据木桶效应，HW 一定不高于 LEO。

4. kafka 中的优化问题

4.1 如何防止消息丢失

在 Kafka 的海域里，防止消息的丢失恰至关键。这就需要水手精准的操作——生产者要如同技术精湛的引导者，消费者像观望远方的瞭望者，及时地做出反馈。

对于生产者来说，可以采用以下方式来防止：

1. 使用同步发送
2. 把 ack 设为 1（0为异步进行数据复制，-1为保证有一个副本复制完成，1为全同步）
3. 同步的分区数 >= 2

对于消费者来说，需要将自动提交改为手动提交，并且当消费完成后再进行 ack 应答。

这相当于网络中的握手过程，消息包收到以后，给出反馈；如果没有收到消息，就让发送端或者 Kafka 重新发一次，以防止消息还没消费就丢失了。

4.2 如何防止重复消费

再精确的海图也免不了失误时出现。为避免消息被重复消费，生产者可能需要更谨慎，而消费者需要有追踪每条消息唯一性的能力。

为了防止消息丢失，当生产者发送完消息后，会根据有无收到 ack 应答去决定是否重新发送消息。

当网络抖动或者其它原因，导致生产者没有收到 ack 时，消费者可能会收到两条或多条相同的消息，造成重复消费。

解决方案有以下两种：

1. 生产者关闭重试机制；
2. 消费者消费消息时用幂等性保证：1）数据库唯一索引；2）Redis 分布式锁。

由于生产者关闭重试后，可能会造成消息丢失，所以我们更推荐让消费者用幂等性或者事务来防止重复消费，这在其它的消息队列中也同样适用。

4.3 如何做到消息的顺序消费

就像在粗犷的风浪中维持航道一样困难，Kafka 的有序消费要求很高。有时需要牺牲性能，专注于单一的分区和消费者。

• 生产者：使用同步发送，ack 设置为 1
• 消费者：主题只能设置为一个 partition 分区，消费组中只能有一个消费者

Kafka 的顺序消费会严重地牺牲性能，所以使用时需要做出权衡。

4.4 如何解决消息积压的问题

消息积压如同海上的风暴，短时间内的消费者可能支撑不过生产者的速度，这时候可能需要更多的船只和船员加入作业。

当消费者的消费速度，远远赶不上生产消息的速度一段时间后，kafka 会堆积大量未消费的消息。

这会导致消费者寻址的速度越来越慢，kafka 对外提供服务的性能也越来越差，从而可能会造成整个服务链变慢，导致服务雪崩。

一般，我们通过多线程或横向扩展的方式来解决：

• 消费者使用多线程消费，充分利用机器的性能；
• 在同一个消费组中创建多个消费者，部署到其它机器上，一起消费。

4.5 实现延时队列

有时，信息需要在特定的时刻获取，就比如火车票待支付订单 30min 后会自动过期。

Kafka 也可设定的延时队列，就像是烹饪师傅精准控制火候，让美食在最佳时间完美呈现。

方案如下：

1. Kafka 中创建相应的主题，并创建消费者消费该主题的消息，消息中带有创建的时间戳；
2. 消费消息时判断，未支付订单消息的创建时间是否已经超过 30 分钟：1）如果是，就修改订单状态为超时取消；2）否则，记录当前消息的 offset，并等待 1 分钟后，再次向 kafka 中拉取该 offset 的消息进行判断，直到支付订单或超时取消。

5. 总结

过去，信号火一点即传，如今，Kafka 使数据能在毫秒之间抵达世界的任何角落。

高可用性的秘密不在于单舰的坚固，而在于整个舰队的协同。

去重、延时、消费顺序的保证，使得 Kafka 成为一个强大且灵活的通信工具。

Kafka 也不仅仅是一个消息队列，它是大数据时代的一艘高速航船，随时准备穿梭于信息的海洋，破浪前行。

而我们，作为水手和指挥官，应当熟悉船上每一个细节，以确保我们的货物——数据，能安全、准确地到达预定的港口。

好了，现在，各位船长，让我们起航吧！

以上分享的Kafka 跟 高可用、顺序消费及幂等性的详细讲解，仅供大家参考建议！