go-zero微服务实战系列（十、分布式事务如何实现）

🚀 优质资源分享 🚀

学习路线指引（点击解锁）	知识定位	人群定位
🧡 Python实战微信订餐小程序 🧡	进阶级	本课程是python flask+微信小程序的完美结合，从项目搭建到腾讯云部署上线，打造一个全栈订餐系统。
💛Python量化交易实战💛	入门级	手把手带你打造一个易扩展、更安全、效率更高的量化交易系统

在分布式应用场景中，分布式事务问题是不可回避的，在目前流行的微服务场景下更是如此。比如在我们的商城系统中，下单操作涉及创建订单和库存扣减操作两个操作，而订单服务和商品服务是两个独立的微服务，因为每个微服务独占一个数据库实例，所以下单操作就涉及到分布式事务问题，即要把整个下单操作看成一个整体，要么都成功要么都不成功。本篇文章我们就一起来学习下分布式事务的相关知识。

基于消息实现最终一致性

我们去店里就餐的时候，付钱点餐后往往服务员会先给我们一张小票，然后拿着小票去出餐口等待出餐。为什么要把付钱和取餐两个动作分开呢？很重要的一个原因是使他们的接客能力更强，对应到服务来说就是使并发处理能力更强。只要我们拿着小票，最终我们是可以拿到我们点的餐的，依靠小票这个凭证（消息）实现最终一致性。

对应到我们的下单操作来说，当用户下单后，我们可以先生成订单，然后发一条扣减库存的消息到消息队列中，这时候订单就算完成，但实际还没有扣减库存，因为库存的扣减和下单操作是异步的，也就是这个时候产生了数据的不一致。当消费到了扣减库存的消息后进行库存扣减操作，这个时候数据实现了最终一致性。

基于消息实现最终一致性这种策略适用于并发量比较高同时对于数据一致性要求不高的场景。我们商城中的一些非主干逻辑可以采用这种方式来提升吞吐，比如购买商品后获取优惠券等非核心逻辑并不需要数据的强一致，可以异步的给用户发放优惠券。

如果在消费到消息后，执行操作的时候失败了该怎么办呢？首先需要做重试，如果重试多次后仍然失败，这个时候需要发出告警或者记录日志，需要人工介入处理。

如果对数据有强一致要求的话，那这种方式是不适用的，请看下下面的两阶段提交协议。

XA协议

说起XA协议，这个名词你未必听说过，但一提到2PC你肯定听说过，这套方案依赖