技术大佬 问我 订单消息乱序了怎么办？

技术大佬 ：佩琪，最近看你闷闷不乐了，又被虐了？

佩琪：(⊙o⊙)…，又被大佬发现了。这不最近出去面试都揉捏的像一个麻花了嘛

技术大佬 ：哦，这次又是遇到什么难题了？

佩琪： 由于和大佬讨论过消息不丢，消息防重等技能（见  kafka 消息“零丢失”的配方 和技术大佬问我 订单消息重复消费了 怎么办？ ），所以在简历的技术栈里就夸大似的写了精通kafka消息中间件，然后就被面试官炮轰了里面的细节

佩琪： 其中面试官给我印象深刻的一个问题是：你们的kafka消息里会有乱序消费的情况吗？如果有，是怎么解决的了？

技术大佬 ：哦，那你是怎么回答的了？

佩琪：我就是个crud boy，根本不知道啥是顺序消费啥是乱序消费，所以就回答说，没有

技术大佬 ：哦，真是个诚实的孩子；然后呢？

佩琪：然后面试官就让我回家等通知了，然后就没有然后了。。。。

佩琪 ： 对了大佬，什么是消息乱序消费了？

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

佩琪 ：低声咕噜了下你这说的是人话吗？大声问答：这对我的小脑袋有点抽象了，大佬能举个实际的栗子吗？

技术大佬 ：举个上次我们做的促销数据同步的栗子吧，大概流程如下：

技术大佬 ：上次我们做的促销业务，需要在我们的运营端后台，录入促销消息；然后利用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+订单更新时间戳，做为数据库佣金表的更新条件，进行数据的乱序处理。

佩琪 ： 哦哦，能详细说说 这个数据库乐观锁是怎么解决这个乱序问题吗？

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

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

佩琪 ：哦哦，明白了。原来一条带条件更新的sql，就具备了乐观锁思想。

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

总结

要想保证消息顺序消费大概有两种方案

固定分区方案

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

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

乐观锁实现方案

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