共计 876 个字符，预计需要花费 3 分钟才能阅读完成。
前言
这篇文章是《对于分布式事务的了解》的后续篇：分布式事务之最终一致性实现计划。
还是那个电商需要，一个订单领取实现后的业务场景，有如下操作：
- 更改订单的状态为“已领取”
- 扣减商品库存
- 给会员减少积分
- 创立出库单告诉仓库发货
咱们应用 最终一致性计划 去实现它。
什么是最终一致性？
从字面上看就是 保证数据最初的一致性 就能够了。
为了缩小零碎代价，如果两头节点解决失败，其余节点个别不会主动回滚，而是通过重试机制和人工参加的形式对失败数据进行解决，从而来保证数据最初的一致性。
实现计划
应用 本地音讯表 + 后台任务 + 音讯队列 + 接口幂等性。
本地音讯表 ：在对应业务数据库中减少的本地音讯表，这张表存储业务产生的音讯，通过 本地事务 保障业务数据和音讯数据的一致性，比方：msg_published 和 msg_received 示意公布音讯表和接管音讯表，在音讯表中会有一个状态来标识业务是否执行胜利。
后台任务：当音讯表中有执行失败的业务信息时，后台任务就会依照配置的重试策略进行重试，例如重试策略为当发送和生产音讯的过程中失败会立刻重试 3 次，在 3 次当前将进入重试轮询；重试将在发送和生产音讯失败的 4 分钟后 开始，这是为了防止设置音讯状态提早导致可能呈现的问题；后续就会每隔 1 分钟之后重试一次，默认的最高重试次数为 50 次，当达到 50 次时，就不会重试了，通过发邮件 / 微信 / 钉钉 / 短信的形式告诉人工去解决，告诉时须要思考音讯降噪。
音讯队列：跨服务之间的调用应用音讯队列，来实现服务解耦。
接口幂等性：接口须要保障同一操作发动的一次申请或者屡次申请的后果必须是统一的。
代码实现
举荐一个 C# 开源我的项目 CAP，大家能够参考一下。
这个我的项目只反对 C# 代码去集成，如果是其余语言能够参考其设计思路，而后进行一个简略的实现。
小结
本文纯属抛砖引玉，有问题，欢送批评指正。
你有更好的实现计划吗？欢送留言~
举荐浏览
- 答复两个被频繁问到的代码写法问题
- 依据使用者反馈，对开源我的项目 go-gin-api 新增两个性能
- 对于解决电商零碎订单状态的流转，分享下我的技术计划（附带源码）
- 我是怎么写 Git Commit message 的？
