Kafka消息策略：搞定消息堆积丢失，关键优化与解决思路

消息堆积于Kafka那时，好多团队的最先反应常常是增添机器或者进行扩容，然而存在一个更径直且成本更低的办法：去创建新的Topic再调整消费逻辑 。

任务重新启动后直接消费最新的消息，对于"滞后"的历史数据采用离线程序进行"补漏"。
如下面图所示。创建新的topic并配置更多数量的分区，将积压消息的topic消费者逻辑改为直接把消息打入新的topic，将消费逻辑写在新的topic的消费者中。

创建新Topic与分区扩容

针对消息积压的情况，首先直接去创建一个有着更多分区的新Topic，此为有效的起始步骤。分区的数量会对Kafka的并行处理能力产生直接影响。举例来说，能够把原Topic的分区数从6个提升到12个或者更多。之所以采用这样的设计，是因为生产者能够把消息均匀地写入新的分区，这为后续的并行消费奠定了基础。在调整分区之后，要重启或者扩容消费者组，使得消费者实例的数量与分区数相匹配，进而才能够充分利用新的并行度。

重构消费者逻辑与数据迁移

随后要处理积压着的数据，有个稳妥的办法是让原消费者组持续运行，不过要对其消费逻辑予以修改，新的消费者代码不再去处理繁杂业务，而是把收到的消息径直转发到新创建的高分区Topic里，这个进程宛如一个数据搬运工，将历史负担迁移至新“管道”，与此同时，针对新建的Topic编写全新的消费者程序，把核心业务逻辑部署在这儿，如此便达成了消费逻辑与数据管道的解耦。

保证消息的局部顺序性

业当中常常会存在要确保同一类消息依照顺序进行处理的需求，比如说同一用户的订单状态发生变更这种情况。在新消费者里，能够借助消息的Key来达成。具体的做法是设置多个相互独立的消息处理队列，像是运用线程池，每个队列都绑定一个单线程。把具有相同Key的消息路由到同一个队列当中，由该队列的单线程按照顺序进行处理，借此就在消费者端保证了局部有序性。博客《一文理解Kafka如何保证消息顺序性》针对此有着更加详尽的阐述。

评估与设置合理分区数

分区数并非是越多便越好呀，设置要是不合理的话，反而极有可能引发问题呢。分区数量应当依据业务吞吐量目标、消费者处理能力以及未来增长情况来进行综合评估哟。比如说呀，有一个日处理千万级消息的日志系统，最开始的时候可能会设置20个分区呢。要是未来数据量实现翻倍了，如此便可以考虑逐步增加到40个哟。与此同时呀，务必要保证消息Key的设计是均匀的，以此来避免因数据倾斜致使个别分区负载过高呀。

提升整体消费能力

唯有增添分区之外，还得整体性地拔高消费链路之容量。倘若消费者处理能力欠缺，就能增添消费者组之内的实例数量，要保证实例数不超出分区总数。与此同时，对Kafka集群自身的资源是不是构成瓶颈予以检查，像磁盘IO、网络带宽以及Broker内存。在必要之时能够扩充集群节点或者升级硬件配置。监测消费者组的延迟指标是察觉到消费能力不足的要点。

实践中的注意事项与监控

需谨慎对待整个方案的实施过程，迁移期间要实现双写或者具备快速回滚能力，必须强化对新Topic以及消费者组的监控，留意消息延迟、错误率与系统资源使用状况，应定期评估分区数量是否依旧合理，依据业务变化动态予以调整，这套组合方案不但解决了当前积压，也构建了一个更具弹性的消息处理架构。

对着Kafka开展性能优化之际，诸位可曾鉴于分区数设定不妥当进而踩到过坑呢？欢迎于评论区域分享自身经历以及解决办法，要是感觉本文颇具助益，还请点赞并且分享给更多同事哟。