【kafka消息里会有乱序消费的情况吗？如果有，是怎么解决的？】

前几天刷着视频看见评论区有大佬问了这个问题：你们的kafka消息里会有乱序消费的情况吗？如果有，是怎么解决的了？以下是我的理解

什么是消息乱序消费了？

消息乱序消费，一般指我们消费者应用程序不按照，上游系统业务发生的顺序，进行了业务消息的颠倒处理，最终导致消费业务出错。

举个例子：

kafka，一般建议同一个业务属性数据，都往一个分区上发送；而kafka的一个分区只能被一个消费者实例消费，不能被多个消费者实例消费。

也就是说在生产端如果能保证把一个业务属性的消息按顺序放入同一个分区；那么kakfa中间件的broker也是顺序存储，顺序给到消费者的。而kafka的一个分区只能被一个消费者消费；也就不存在多线程并发消费导致的顺序问题了。

比如上面的例子；不就是两个消费者，拉取了不同分区上的数据，导致消息乱序处理，最终数据不一致。同一个促销数据，都往一个分区上发送，就不会存在这样的乱序问题了。

能给一个 kafka 指定发送到固定分区的代码吗？

有的，只需要一行代码

java 复制代码

KafkaProducer.send(new ProducerRecord[String,String](topic,key,msg),new Callback(){} )

topic：主题，这个玩消息的都知道，不解释了

key: 这个是指定发送到固定分区的关键。一般填写订单号，或者促销ID。kafka在计算消息该发往那个分区时，会默认使用hash算法，把相同的key，发送到固定的分区上

msg: 具体消息内容

订单算佣业务了，也是利用kafka监听订单数据变化，但是为什么没有使用固定分区方案了？

把订单支付消息，和订单退款消息拆分为了两个topic，这个从使用固定分区方案的前提里就否定了，我们不能使用此方案。

主要是根据自身业务实际特性；使用了数据库乐观锁的思想，解决先发后至，后发先至这种数据乱序问题。

我们算佣业务，主要关注订单的两个状态，一个是订单支付状态，一个是订单退款状态。

订单退款发生时间肯定是在订单支付后；而上游订单业务是能保证这两个业务在时间发生上的前后顺序的，即订单的支付时间，肯定是早于订单退款时间。所以主要是利用订单ID+订单更新时间戳，做为数据库佣金表的更新条件，进行数据的乱序处理。

当佣金表里订单数据更新时间大于更新条件时间就放弃本次更新，表明消息数据是个老数据；即查询时不加锁；

而小于更新条件时间的，表明是个订单新数据，进行数据更新。即在更新时利用数据库的行锁，来保证并发更新时的情况。即真实发生修改时加锁。

我们算佣业务其实是只关注佣金的最终状态，不关注中间状态；所以能用这种方式，保证算佣数据的最终一致性，而不用太关注订单的中间状态变化，导致佣金的中间变化。

1、生产端指定同一类业务消息，往同一个分区发送。比如指定发送key为订单号，这样同一个订单号的消息，都会发送同一个分区

2、消费端单线程进行消费

如果上游不能保证生产的顺序；可让上游加上数据更新时间；利用唯一ID+数据更新时间，+乐观锁思想，保证业务数据处理的最终一致性。