订单系统分布式环境消息顺序处理

最新推荐文章于 2025-02-18 15:22:09 发布

tom3mao

最新推荐文章于 2025-02-18 15:22:09 发布

阅读量1.1k

点赞数

分类专栏： java 文章标签：分布式中间件队列多线程

本文链接：https://blog.csdn.net/j16421881/article/details/108298203

版权

消息为什么要顺序消费

一个订单会有很多种状态：待支付、已支付、待发货、交易完成等等。

每一种状态的流转都依赖上一个状态，其中一些状态是不可逆的，例如不能从已支付退回待支付。

订单状态流转就是一个典型的状态机场景，如图所示。

订单基于状态机设计模式可以很方便实现乐观锁，在分布式环境，可能多个实例同时将订单从一个状态更为为另一个状态，基于MySql的MVCC多版本并发控制，只有一个线程能更改成功。基于状态机的乐观锁保证了在微服务环境下的线程安全。

UPDATE  order SET status = '已支付' WHERE status = '待支付' AND order_id = 10001
UPDATE  order SET status = '已发货' WHERE status = '已支付' AND order_id = 10001

update语句涉及对数据库的更改，MySql会按顺序产生对应的binlog，可以基于Alibaba开源中间件Canal订阅binglog，实现订单消息的准实时收集，例如推送给ElasticSearch。订阅binlog一大好处就是业务逻辑不需要关心 ES 数据的写入。在大批量下单，活动、秒杀场景可能有大批量的binlog变更，如果直接通过Canal订阅binlog变动，会造成Canal Client瞬间爆掉。为了解决这个问题，我们可以引入kafka做一层封装，起到削峰作用。消息是异步的，基于消息投递的更新和删除的操作，如果出现了先发后至/后发先至的情况，就会导致ES里的数据是比较旧的数据，如果待支付消息覆盖了已支付消息是不允许的。