彻底搞透分布式一致性( 八 ) _分布式

业务迭代引入 bug 会破坏事务机制：这个就更常见了，由于bug导致流程错误，不得不修复问题和数据

除了主动降低不一致性概率，还需要添加一些被动保护机制，也就是常说的业务补偿。
4.1. 查询模式查询模型是最常用的一种方式，主要用于应对网络传输中的第三态问题。
第三态指的是在分布式系统中，在进行跨网络调用时，调用方无法确定被调用方的状态是否改变了，因为这两者之间存在一段未知而不可控的网络延迟时间，导致调用方无法立即得到被调用方的结果。这种情况下，第三态可以看做是一个未知的状态，需要通过一些机制来解决这个问题。

文章插图
图片
当网络调用出现第三态时，最简单的方式便是对不确定的状态进行查询，如上图所示：

调用方调用服务完成业务操作，如果成功拿到执行结果，则直接进行后续流程；
如果发生网络超时，将通过状态查询接口来检查之前的操作是否完成，如果：

已完成，则继续执行后续流程；
未完成，在重新发起业务调用；
RocketMQ 的事务消息便是基于该机制进行实现。
4.2. 任务检测模式当一个业务操作完成后，需要处理多个后续任务，为了保障所有任务都会被执行，可以使用该模式。
如下图所示：

文章插图
图片
image

业务操作后，将业务变更和检测任务在同一事务保护下进行入库；
系统继续执行后续任务，执行完成后对任务状态进行更新；
系统周期性对超时未执行的任务进行加载，并进行检测，如果

已经执行，则更新任务状态
如果未执行，则触发任务执行
本地消息表就是基于该模式进行构建。
4.3. 对账模式对账模式经常出现在与银行等金融机构对接的场景。

文章插图
图片
业务对账思路非常简单：

从不同的业务系统获取对账数据；
按照规则进行双向对账，如果

一致，则说明系统一致
不一致，进行报警，人工介入进行处理
必须是双向对账，单向对账会出现数据丢失情况。
5. 小结一致性是分布式系统面临的巨大挑战，根据不同场景可以将一致性分为：

事务一致性。在一个事务内的所有操作，要么全部完成，要么全部不完成，即保证这些操作是对数据的一致更新，避免数据出现不一致的情况。主要通过使用事务保证来实现，例如：关系型数据库的ACID事务。
副本一致性。各个副本之间的数据保持一致。当数据发生变化时，需要将这个变化同步到所有的副本中。主要使用副本同步技术来实现，例如MySQL的主从复制、MySQL 到 Redis的数据同步；

本文重点对事务一致性进行全方位的阐述，包括：