持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第16天，点击查看活动详情

每日英语:

The limits of my language means the limits of my world.

翻译：我语言的边界，即我世界的边界。 ——维特根斯坦

RocketMQ事务消息

在RocketMQ中生产者有三种角色 NormalProducer（普通）、OrderProducer（顺序）、TransactionProducer（事务） ，根据名字大概可以看出各个代表着什么作用，我们这里用 TransactionProducer（事务）来解决问题。

最终一致性案例分析

我们在前面已经完成了下订单操作，但如果用户完成了支付，此时需要通知当前系统处理订单状态，并增加用户金币，不过大家可以发现个问题，其实用户支付完成后，订单状态并非立即发生改变，很多时候都是过了一会儿订单状态才发生改变、奖励的金币才到账，这是因为支付系统和订单系统是独立系统，最主要的是支付业务和订单业务并不需要数据强一致性，最终一致即可。

我们举个例子，比如用户支付成功了，但赠送金币失败了，这个时候就需要给用户退款吗？很明显是不需要的，只需要处理下赠送金币的流程即可。

上图是支付流程设计：

1:用户下单成功后，会进入支付
2:支付需要从我们支付系统中获取支付二维码
3:用户支付完成后，微信服务器会将支付结果返回给我们的支付系统
4:支付系统会在本地数据库中做一个支付结果保存，同时通过RocketMQ将支付结果告知订单系统
5:订单系统读取RocketMQ支付结果，并发起订单状态变更以及赠送积分操作

上述流程中4-5两个流程可以采用RocketMQ事务消息实现事务最终一致操作。

总结

本篇主要介绍了一下RocketMQ事务消息中的TransactionProducer（事务）的大致流程，以及对最终一致性案例分析