架构师一口气说透分布式数据一致性问题

这是我的第42篇原创

今天聊聊分布式环境下数据一致性的各种解决方案。有点烧脑，但是很有趣。

单体环境中的一致性问题

在传统关系型数据库环境（单体环境，或者叫单机）中，自己记录自己的就行了，单机环境不存在环境数据一致性的问题，倒是有并发操作数据一致性的问题。

对于一个数据库操作（专业术语叫：事务）来说，总结出4个特性：原子性、一致性、隔离性和持久性，合称ACID，我们不需要记那么多，只需要知道这些特性就是能保证数据库里的数据能够准确就行了。

原子性（atomicity）：一个事务中的所有操作，不可分割，要么全部成功，要么全部失败；
一致性（consistency）：一个事务执行前与执行后数据的完整性必须保持一致；
隔离性（isolation）：一个事务的执行，不能被其他事务干扰，多并发时事务之间要相互隔离；
持久性（durability）：一个事务一旦被提交，它对数据库中数据的改变是永久性的。

为了防止很多人一起操作，数据库会大量使用锁。锁就是在你操作这条数据的时候，加一个状态位，别人就无法操作了，类似于你上厕所的时候锁门一样。\

在上图中，有两个业务操作同时要修改关于的等级，但是业务操作3拿到锁了，所以操作之后，关羽的等级会变成35。业务操作2会因为这条记录被锁，而执行失败。

单机数据库环境（传统数据库），用的大多是悲观锁，意思就是用悲观的态度对待数据库修改，假定任何一次拿数据都可能遇到有人会修改：

在你修改这条数据的时候，数据库会自动帮你对条记录上个锁，别人就无法在你改数据的时候同时修改了，这叫行锁；
在你改这个表的时候，数据库也会给表上锁，这叫表锁；
在你读取数据的时候上锁，就是读锁；
在你写数据的时候上锁，这就是写锁。

分布式环境中的一致性问题

但是分布式环境，就不一样了。锁是面对并发任务的，解决多个任务抢一个资源的问题。分布式的时候也会面临这个问题，用的是分布式锁解决。

但是分布式本身会导致另外一个问题：分布式是集群环境，集群环境会存储多个副本，这个时候问题来了，既然一份数据会存储多个副本，集群怎么保证多个副本中的数据都是一样的？又怎么最终保证修改完数据后，我们去读取这个数据，就是刚刚改好的数据呢？

之所以有这个问题，就是因为分布式环境是多个小数据库组成集群，而网络通讯出现异常是集群建设的前提假设。也就是说，当业务操作1修改关羽等级的时候，就可能出现三个副本的数据不一致的情况。副本1、2已经改好了，副本3因为网络延迟，还没改好；这时业务操作2读取关羽等级的时候，如何保证能读取到最新的数据？这就是分布式环境中的数据一致性的额问题。

CAP定理

为了研究分布式数据一致性的问题，IT届吵吵了很久，2000年，Eric Brewer在国际会议上提出了CAP猜想，2002年，Lynch与其他人证明了Brewer猜想。这个被证明的CAP定理如下：

C一致性，即所有副本的数据都是一致的；
A高可用性，即一部分节点出现故障，能够响应客户端的读取请求\
P分区容错性，分布式环境中，即出现网络分区时，也能使客户端拿到最新数据
C\A\P无法同时满足，最多只能同时满足其中两项。

其中P（分区容错性）是必须的，也就是说，我们只剩下CP和AP两个选择。要么抛弃数据一致性，追求高可用，要么抛弃高可用，追求数据一致性。而这两个结果都不是我们想要的。这可咋办？

BASE理论

这个世界总是有英雄站出来。eBay的架构师Dan Pritchett提出了BASE理论：

Basically Availble，基本可用（CAP中的A，高可用）
Soft-state，软状态/柔性事务
Eventual Consistency，最终一致性（CAP中的C，数据一致性）

所有的非金融的应用场景中，我们都遵循BASE理论，提供基本可用和最终一致性的服务。

Quorum机制

正是基于CAP和BASE理论，才有了Quorum机制，来解决分布式环境中数据一致性的问题。quorum机制又叫NRW机制，允许集群中有不一样的情况，但是只要能保证读取的时候有新的数据就行了，NRW即：

N=总节点数
R=read，读取的副本数
W=write，写入的副本数
拿到最新数据所需要读取的副本数共需：R=N-W+1，W越大，写入的概率越小，读取的压力就越小；W越小，写入的概率越大，但是读取的节点数就越多，读取的性能越差

以上图为例，假设业务操作1进行修改关羽等级的时候，只有两个节点修改成功了，那么业务操作2进行读取的时候，必须要读取R=N-W+1=3-2+1=2个副本就能获取到最新的数据。你看，我们无需所有节点都一致，也能达成数据可用的效果。至于那个还没改好的节点，集群的数据同步机制会慢慢同步的。

那么有没有让所有节点都一次性全部成功写入的方法呢？有的，方法还不少。

强一致性解决方案

目前主流的强一致性解决方案有4种：

2PC（2 phase commit）2阶段递交法
3PC（3 phase commit）3阶段递交法
4PC（笑） TCC（try-cancel-commit）试一下，不行就算了递交法
消息中间件一致性解决方案

基本上跟TCP/IP三次握手的逻辑是一样的，2PC就是经过两个阶段，最后递交事务；3PC就是经过3个阶段，最后递交事务；TCC就是尝试、取消、递交；Half MQ就是先占坑，确认后再递交。

2PC分为两个阶段：投票阶段和操作阶段。既然是投票，就得有一个人从中协调，要不怎么保证公平呢。所以2PC引入了一个协调者coordinator。一个分布式事务请求过来，先到协调者这边，协调者发起第一阶段即投票阶段，问所有的参与者：你们准备好了吗？所有人回答：准备好了！然后协调者发起第二阶段即递交阶段说：兄弟们，改吧。然后所有参与者发起本地事务把关于的等级改成34级。如果有人说：我这还没好，那么协调者也会发起第二阶段，只不过就变成了取消操作。

这就跟跑步比赛一样，第一阶段：裁判喊“准备~~”；第二阶段：裁判喊“跑”！

2PC比较耗资源，因为所有人的资源都锁着，一直等到所有人都答复了才能递交/取消，万一有节点甚至是协调者掉线那就麻烦了，全得等着。

3PC是在2PC的基础上做了一些优化，在2PC的两个阶段之间，增加一个“预执行”Percommit的阶段，这样就变成了3个阶段：CanCommit、PerCommit、DoCommit。

这还跟跑步比赛一样，第一阶段：裁判喊“各就位~~”；第二阶段：裁判喊“预备~~~”；第三阶段：裁判喊“跑”！

3PC由于增加了预执行的操作，不会造成长时间锁资源，而且增加了超时自动递交的规则，效率大大增加。

但是万一有些节点超时的时候，有些节点告诉协调者他准备失败，然后协调者取消了任务咋办？这样还是会导致数据不一致。

TCC实际上是在业务逻辑层实现的，就是写业务代码的程序员完成的。2PC、3PC都是资源层实现的，是底层的逻辑封装好的。TCC就是Try、Cancel、Commit，这不是跟2PC一样的么？准备-取消or执行。所以很多程序员在看TCC和2PC的时候会感觉这俩很像。TCC的优势是应用自己定义数据库操作的粒度，降低锁的冲突，提高吞吐量。

TCC的问题在于每个业务都要写一次TCC。太繁琐了。有没有更好的解决办法呢？