1. 介绍
之前也写过一些文章总结分布式场景下的一致性处理：
- 最终一致性的保证策略
- 分布式事务的典型处理方式:2PC、TCC、异步确保和最大努力型
- 事务与分布式事务原理与实现2（笔记）
- 从分布式数据复制一致性问题到paxos算法的理解（第一部分）
- 从分布式数据复制一致性问题到paxos算法的理解（第二部分）
今天群里小伙伴，拿着paxos的论文来文一致性问题，正好我也借机复习了下。本文将以比较简单的语言总结下分布式场景下如何处理一致性。本文不介绍具体的实现细节，侧重在实用的解决方案上。
2. 分布式一致性的三种需求场景
分布式对一致性有需求的场景可以归纳为两种：
- 数据副本的一致性
- 分布式事务的一致性
- 数据库数据同步一致性
3 数据副本的一致性
3.1 定义
分布式场景下，同一个数据分片需要在多个节点上保存多个副本并保证复制的副本之间的一致性。
3.2 可用协议
这种场景可用的协议一般来说是Paxos协议。基于该协议衍生的zab协议实现的zookeeper是对应的主要产品。
为啥是说一般来说？因为我只能说现在主流的解决方案都是以paxos协议实现的产品，例如zookeeper。但是技术是发展的，这种需求也会有其他的协议或者算法来解决。
下文的使用场景的解决方案都是基于该协议的，请悉知。
3.3 实际使用场景
paxos协议主要侧重在分布式场景下多副本的一致性。其衍生产品是zookeeper。所以我们在讨论该协议应用的场景，其实可以理解为zookeeper的应用场景。ZK的使用场景主要是存储一些重要的元数据，维护和监控存储数据的状态变化。利用ZK的这个特性就会衍生出以下的使用场景：
- 分布式存储的元数据管理：例如HDFS、HBASE等一些分布式存储相关的产品。
- 配置中心和命名服务：一些元信息（当然也包括一些全局的唯一ID命名）在分布式环境中的存储和更新，可以用在配置中心和命名服务上。底层实现就是通过paxos协议来实现全局的分布式锁。
- 容错和高可用： 可以做一些故障转移、leader选举。
- 状态管理：有时候需要把产品的一些组件做成无状态的，这时候状态信息可以交给zk来管理。
PS：当然以上说的使用场景并不一定要使用paxos协议。例如kafka当中的分区leader选举就没用zk的quorum模式，主要ZK不适合主数据存储，会有性能问题。
4 分布式事务的一致性
4.1 场景需求
分布式事务按照是ACID特性还是BASE特性分成了刚性事务和柔性事务。针对分布式事务的一致性，针对刚性事务和柔性事务都有一些不同的解决方案。而这些解决方法一般可以分为事前控制和事后控制。一般事后控制，都属于柔性事务了，即追求最终一致性。
4.2 刚性分布式事务一致性解决方案
- 2PC（两阶段提交协议）
- MVCC（多版本控制并发）
- 异步确保：通过将同步阻塞操作变成异步操作，从而避免资源竞争来减少同时修改一份数据的概率来减少一致性问题。这种策略只是一种优化，并不能完全解决一致性问题，只是降低一致性问题出现的概率。
- 采用paxos协议，来保证修改操作的一致性。
以上的1,2两点的解决方法很多数据库都已经提供了支持，例如Mysql或者Oracle之类的。第3,4点的解决方案则需要自己开发产品咯。
4.3 柔性分布式事务一致性解决方案
- TCC（try-confirm-concel,补偿性事务）: 即A和B两个事务，A事务先尝试提交，如果事务B失败回滚了，对已经提交的A事务做反操作。
- trusted source(信任站点)：信任站点，数据出现冲突时，永远以某一边为准覆盖另一边
- timestamp：基于数据的修改时间戳，修改时间新的覆盖旧的数据
- 数据类型merge， 比如针对库存信息，A地库存减一，B地库存减二，两边同步之后A地和B地的数据应该是减三，合并两者减一和减二的操作
5.数据库数据同步一致性
数据同步的时候，也会讨论一致性。这种一致性的解决，也可以分为事前控制和事后控制。关于这个在otter的wiki上有较为详细的介绍，刚兴趣的可以看下。
数据库数据同步的一致性其实可以归结到上述分布式事务的一致性，大家可以参考着一起看。