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

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

什么是消息乱序消费了？

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

顺序生产，顺序存储，顺序消费

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

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

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

能给一个 kafka 指定 发送到固定分区的代码吗？
有的，只需要一行代码

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+数据更新时间，+乐观锁思想，保证业务数据处理的最终一致性。