在分布式的服务架构中，不同的服务 部署在不同的服务节点上各自以独立进程的方式运行，节点之间需要进行网络才能通讯交互。大家比较熟知电商系统下单购买商品的场景，假设 我们的订单系统，支付系统都是独立部署的微服务，用户在购买商品下单时 会有生成订单 和支付扣款 两个动作，两个动作需要保证都成功或者都失败，两个服务之间怎么保证分布式事务数据一致性的问题呢？
在很多系统业务场景中，我们需要处理业务数据的一致性的问题，来保证业务的正常。比如 MySQL 在执行 变更操作时， redolog 和binlog 需要保证 同时写入成功，才能保证当MySQL发生因异常发生崩溃恢复后，主库从库数据是一致的。MySQL 在这个过程中 是 用的二阶段提交(2PC)的方式 来保证的，是强一致性的一个解决方案。
强一致性的解决方案适用于事务协调者和参与者不需要走网络通信的单体系统服务， 因为网络的世界是不可控，在分布式的系统中并不适合，事务协调者和参与者每一次的交互都有可能因为网络问题导致通信异常，进而导致数据的不一致性，最终只能退化成最终一致性解决方案。
综上所述，强一致性 在分布式系统中行不通，必须使用最终一致性的解决方案。最终一致性解决方案 又细分为如下几种方案：
1. 可靠事件模式
可靠事件模式在实际项目中应用较多，比如优秀的开源消息队列 RocketMQ 消息最终一致性的实现就是基于可靠事件模式。
此模式需要一个事务协调服务参与，此服务我们暂且叫可靠消息服务，主要负责协调上下游数据信息的传递，来保证数据一致性的，他的基本原理步骤如下：
1.1 上游应用执行本地事务成功并发送MQ消息通知下游。
● 上游服务 先把 本地要执行的事务消息先发给 可靠消息服务，可靠消息服务写入成功，消息状态 置为 “待确认”，然后返回 OK 给上游服务。
● 上游服务收到返回的OK 之后执行本地事务。
● 执行成功之后同步到可靠消息服务，可靠消息服务往 MQ 队列里同步发送消息，消息发送成功后， 消息状态 置为 “ 已发送”
1.2 下游应用监听MQ 消息并执行本地事务。
● 下游服务 监听MQ消息 消费 处理执行 本地事务。
● 处理完成之后 向MQ 发送 Ack 消息确认已经消费。
● 下游服务 通知 可靠消息服务，将消息 状态 改为 "已完成"。
以上就是可靠事件模式的大概的实现方案，具体实战场景 可结合如上所提的 电商中支付和生成订单 等脑补整个流程。
系统可能存在的问题及应对方案
● 当步骤1.1 中 消息状态 置为 “待确认” 后 上游服务执行本地事务，到达了设定的超时时间消息状态一直未更改。
此时说明上游服务 和协调者 有可能存在网络通信问题，需要上游服务提供接口，协调者主动去查上游服务的执行状态，若上游服务事务执行成功，则更新状态，走后续的流程；若执行失败则终止事务。
● 可靠事件服务 向MQ 中发消息的过程可能会发送异常。
我们需要采用同步发送的模式，发送成功和失败能同步感知，失败可定期重试，保证数据发送成功。
● 当步骤1.2 中 消息状态 置为 “已发送” 后，过了设定的超时时间 消息状态 一直未发送更改。
此时下游服务可能发生了异常或者与协调者网络通信出了问题，发送的通知并没有收到。解决办法就是进行消息重发，此处要特别注意，下游的消费服务要保证 处理消息的幂等性。
● 步骤1.2 中 下游服务应该采取怎样的消费策略来保证数据不丢失能被正确消费处理？
为了保证数据一定被消费到，且兼顾数据处理速度，我们可以采取手动ack 和批量消费的方式，每次消费一批数据，然后统一提交offset。topic 中多分几个patition，消费组中多起些消费者同样也可提高数据处理能力。
● 若批量消费的数据中有处理失败的怎么办？
可以加一个失败的消息队列，有失败的消息打入到此消息队列中，稍后处理。
2. 补偿模式
补偿模式顾名思义，其原理比较简单就是 发现问题、及时纠偏。
如何发现问题呢? 有如下两种方式，采用哪种方式根据业务情况做相应取舍。
● 主动发现。
可通过设置定时任务的方式，定时核对数据，发现异常数据，定时重试修复。
● 被动发现
服务不主动扫描数据，当用户请求相关数据的时候，进行自我核对、自我修复。
此方案优点：
减少了大批量数据的核对工作，减少了瞬时压力。并发访问量不高的数据服务可以这么做。
缺点：
核对修复会占用一部分时间，服务性能会受到一丝影响。
附相关思维导图
以上就是个人关于分布式系统中数据一致性解决方案的理解梳理，有不对的地方欢迎各位大佬补充批评指正！
#头条创作挑战赛#