一、概述：
在日常的工作场景，经常遇到数据一致性相关的问题，各路大神在应对各类问题时，也开发出了各种优秀的技术组件，接下来汇总一下，希望对大家学习有帮助.
二、单机环境下，多线程并发：
在单机多线程并发情况下，如何保障对共享数据的安全访问？相信有经验的开发人员，应该都能回答出来，多线程并发涉及的知识点Synchronized,ReentrantLock，CAS操作通过获取对象锁修饰代码块或者方法，来确保对共享变量的安全访问，来保障逻辑上的一致性。
三、数据库事务：
以mysql为例，MySQL XA 是基于Open Group 的<<Distributed Transaction Processing:The XA Specification>> 标准实现的，支持分布式事务，允许多个数据库实例参与一个全局的事务。MySQl XA 从MySQL 5.0 开始引入，众多的存储引擎当中，仅innodb存储引擎支持MySQL XA事务。
1、事务的特征ACID
A 原子性
C 一致性
I 隔离性
D 持久化
2、事务的隔离级别
Read Uncommitted（读取未提交内容）
Read Committed（读取提交内容）
Repeatable Read（可重读）
Serializable（可串行化）
3、事务的传播特性
七种事务的传播特性
四、CAP理论：
C表示一致性，各个副本节点上，数据需要保持一致性;
A可用性;
P分区容错性，分布式环境下，当有网络，环境等等问题，必须得让系统持续对外提供服务保障；
五、BASE理论：
BA 表示基本可用
S 表示Soft status ，可以容忍中间状态的存在；
E 表示最终一致性；
相对传统的事务强调强一致性，互联网分布式事务，更多的采用柔性事务，例如电商下单，同时发放优惠券，发放优惠券的动作，可以采用异步的方式，例如存放工单表，后台定时任务扫描工单表，负责处理发放优惠劵的动作。
再例如Zookeeper 主从节点数据同步，采用超过一半确认，就可以提交的方式，也是采用柔性事务，只要达成事务最终一致性就OK。
六、分布式锁：
分布式锁，相对单例模式下并发线程的锁，当需要控制多个实例上面的线程操作某个共享变量时，分布式锁显得尤为重要，当获取锁，才可以业务操作，否则等待。可以采用curator、redis等相关中间件，实现分布式锁。
七、分布式事务：
当事务控制多个数据库实例时，需要有个事务管理器TM管理多个资源管理器RM，通过XID标识同一个事务，分布式事务的实现方案有以下两种：
1、2PC：
两阶段提交又称2PC（two-phase commit protocol）,2pc是一个非常经典的强一致、中心化的原子提交协议。这里所说的中心化是指协议中有两类节点：一个是中心化协调者节点（coordinator）和N个参与者节点（partcipant）。
2、3PC，
三阶段提交（Three-phase commit），也叫三阶段提交协议（Three-phase commit protocol），是二阶段提交（2PC）的改进版本。
与两阶段提交不同的是，三阶段提交有两个改动点。
- 引入超时机制。同时在协调者和参与者中都引入超时机制。
- 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。
也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。
2PC与3PC的区别
相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的消息后，会默认执行commit操作，而不会一直让事务处于阻塞状态。但是也有可能会造成数据不一致。例如：当一部分机器收不到协调者信息，这时候协调者发送的abort信息，这样的话，一部分机器commit，一部分rollback，就会导致数据不一致。
3、TCC
TCC分别对应Try，Confirm和Cancel三种操作，三个操作业务含义如下：
Try：预留业务资源
Confirm：确认执行业务操作
Canal：取消执行业务操作
与关系型数据库事务的三个操作作对比：DML、Commit，Rollback
| 操作 | TCC | 关系型数据库事务 |
|---|---|---|
| Try/DML | 预留业务资源 | 锁定数据库记录行 |
| Confirm/Commit | 确认后，使用预留资源 | 对锁定记录航进行操作 |
| Cancel/Rollback | 没有全部成功就回滚 | 没有全部成功就回滚 |
TCC和两阶段分布式事务处理的区别
当讨论2PC时，我们只专注事务处理阶段，因而只讨论prepare和commit，所以，可能很多人都忘了，使用2PC事务管理机制也是有业务逻辑阶段的。正是因为业务逻辑的执行，发起了全局事务，这才有其后的事务处理阶段。所以，实际上，使用2PC机制时，以提交为例：
一个完整的事务周期：
begin–>业务逻辑–>prepare–>commit。
再看TCC，也不外如是：要发起全局事务，同样也必须通过业务逻辑来实现。该业务逻辑一来通过执行触发TCC全局事务的创建；二来也需要执行部分数据写操作；此外还要通过执行想TCC全局事务注册自己，以便后续TCC全局事务commit/rollback时回调其相应的confirm/canal业务逻辑。所以，使用TCC机制时，以提交为例：
一个完整的生命周期：
begin–>业务逻辑(Try业务)–>commit(confirm业务)。
综上所述：将两个机制做对应：
1、2PC机制的业务阶段 === TCC机制的try业务阶段
2、2PC机制的提交阶段(prepare & commit) ==== TCC机制的提交阶段(confirm)
3、2PC机制的回滚阶段(rollback) === TCC机制的回滚阶段(cancel)
八、幂等：
所谓幂等，就是当客户端发起功能重试时，N次操作，都跟第一次操作结果相同，例如查询就是天生的幂等；下单，如果客人重复提交下单，这时系统不能生成很多重复的订单，这就需要幂等的判断处理。
可以根据请求的入参组装起来求取hashcode ，如果值跟现有库中数据相同，表示已经有相同的请求，系统则自动返回，不会再重复生成一条订单。