此次分享的缘由
支付重构
考虑支付重构的时候，自然想到原本属于一个本地事务中的处理，现在要跨应用了要怎么处理。拿充值订单举个栗子吧，假设：原本订单模块和账户模块是放在一起的，现在需要做服务拆分，拆分成订单服务，账户服务。原本收到充值回调后，可以将修改订单状态和增加金币放在一个mysql事务中完成的，但是呢，因为服务拆分了，就面临着需要协调2个服务才能完成这个事务。
所以就带出来，我们今天要分享和讨论的话题是：怎么解决分布式场景下数据一致性问题，暂且用分布式事务来定义吧。
同样的问题还存在于其他的场景：
送礼：
1. 调用支付服务：先扣送礼用户的金币，然后给主播加相应的荔枝
2. 确认第一步成功后，播放特效，发聊天室送礼评论等充值成功消息：
1. 完成充值订单
2. 发送订单完成的kafka消息在涉及支付交易等付费接口的时候，数据一致性的问题就显得尤为重要，因为都是钱啊
目前分布式事务是怎么解决的呢？
问题肯定不是新问题，也就是目前已经有相应的解决方案了，那就看一下现在是怎么来解决这类问题的吧。
以购买基础商品成功后发送支付订单完成消息为例：
假设支付下单购买基础商品，此刻已经收到支付回调，订单已经处理成功了，这个时候kafka服务故障，消息发送失败；而这个时候处理订单的事务已经提交了，怎么保证订单完成的消息一定能发出去呢？
解读一下这个流程：
绿色部分，表示流程正常运行的交互过程：
黄色部分，表示流程出现了异常，数据可能存在不一致现象。这个时候就需要进行流程恢复
问题：
行业中有什么解决方案
说解决方案之前，我们先了解一下这些方案的理论依据，有助于帮助我们来理解和实践这些方案
理论依据（讨论的前提）
本地事务、分布式事务
如果说本地事务是解决单个数据源上的数据操作的一致性问题的话，那么分布式事务则是为了解决跨越多个数据源上数据操作的一致性问题。
强一致性、弱一致性、最终一致性
从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性.
从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。对于分布式数据系统：
- N — 数据复制的份数
- W — 更新数据时需要保证写完成的节点数
- R — 读取数据的时候需要读取的节点数
如果W+R>N，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库，N=2,W=2,R=1，则不管读的是主库还是备库的数据，都是一致的。
如果W+R
