kafka partitioner和消息有序性

最新推荐文章于 2025-05-07 14:37:53 发布

高级Java进阶之路

最新推荐文章于 2025-05-07 14:37:53 发布

阅读量816

点赞数 1

CC 4.0 BY-SA版权

分类专栏：深入掌握Java面试问题互联网大厂工作、成长、晋升之路文章标签： kafka elasticsearch java

本文链接：https://blog.csdn.net/liuzhengyang1/article/details/124742012

互联网大厂工作、成长、晋升之路同时被 2 个专栏收录

20 篇文章 ¥29.90 ¥99.00

订阅专栏

超级会员免费看

深入掌握Java面试问题

14 篇文章 ¥49.90 ¥99.00

订阅专栏

超级会员免费看

本文介绍了Kafka中Partitioner的工作原理，以及如何保证消息的有序性。消息的分区主要由producer决定，通过指定partition或自定义Partitioner实现。有序性通常是指业务对象维度的顺序，如订单状态或用户行为。使用相同key发送到同一partition可确保在consumer内部的顺序。DefaultPartitioner根据key的hash值分配partition，key为null时采用StickyPartition策略。然而，StickyPartition可能引发‘弱者越弱’问题，导致处理延迟。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

通过本篇文章，我们能了解kafka默认的Partitioner如何决定消息的partition，以及如何保证消息的有序性。

一个消息要发送到哪个partition是由producer决定的。

指定partition的需求大部分来自于消息有序性的保证。例如一个关注系统会在用户关注、取关行为后发出关注、取关的消息，另一个系统消费这个消息，比如用来更新缓存，关注加缓存、取关删除缓存。如果顺序出现错误比如先收到了取关消息后收到关注消息，则可能导致关注的缓存状态不对。再例如一个订单系统会将订单的状态变化通过消息发送，另一个系统订阅这个消息，把订单的状态同步到ElasticSearch中方便管理后台查询，如果订单状态的消息不能保证顺序，则可能导致ElasticSearch中保存的不是订单的最终状态。

上述的顺序性，并不需要严格的全局顺序，而是某个业务对象维度的顺序性，比如订单系统按照订单号维度保证顺序、用户关注取关消息按照发起用户id维度保证顺序即可。

而利用kafka中每个partition中的消息会按照发送顺序保存，并且同一时间内被consumer group中唯一一个consumer消费，在consumer进程内通过保证同一个key由相同的线程执行，就可以保证消息消费的顺序性，所以把同一个业务key的消息发送到同一个 partition上就可以保证整体的有序性。

要指定一个消息的partition有两种方法，一种是在调用Producer