浅谈分布式系统的一致性协议（一）

2019 年 10 月 8 日
笔记

我们在Mysql系列文章中已经介绍过，我们常用的InnoDB存储引擎是支持事务的。这里所说的事务由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元。事务保证了这一组操作要么都成功，要么都失败；并且事务提交之后，数据不会丢失。总结下来就是原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），即ACID四个特性。这种事务是针对单个数据库的，数据库底层只是在单个计算机内部通过一系列机制实现了ACID特性，不需要与其他外部数据源进行交互。从系统架构上划分，这属于集中式系统架构，这也符合早期做的传统软件项目的特点，没有负载均衡，都是单机运行，而数据库也是单台，只是做数据库备份，在主库宕掉时，切换到从库即可。

进入互联网应用爆发的今天，很多企业所面临的的场景，已经不再是集中式架构，取而代之的是分布式架构，比较代表的就是阿里的去IOE（IBM-服务器提供商，Oracle-数据库软件提供商，EMC-存储设备提供商）运动。一方面分布式系统为企业带来了成本的减少，另一方面也带来了各种复杂的问题和挑战：

分布、对等、并发：

在分布式系统架构里，各个节点没有主从之分、所有机器都是对等的，并且所有的节点可能分布在不同的网络当中，互相之间通过网络进行交互，而且这些节点可能会在同一时间竞争一些共享的资源，这就需要我们在构建分布式系统应用时，应该准确且高效的解决这些并发问题；

时钟问题：

分布式系统还有一个时钟问题，在单台计算机内部，由操作系统内核或硬件提供时钟系统，来协调计算机内部事件执行的先后问题；而分布式系统缺乏一个全局的时钟序列控制；

故障问题：

分布式系统的所有节点，都可能会不可避免的发生各种情况的故障。分布式系统的黄金定理，任何在设计阶段考虑到的异常情况，一定会在系统实际运行中发生，并且，在系统实际运行过程中还会遇到很多设计时未能考虑到的异常故障。

根据分布式系统常见的故障问题，总结如下：

1、通信异常

网络通信问题是分布式系统不可避免的因素，各个节点之间的通信都会伴随着网络不可用的风险，消息丢失和消息延迟的问题普遍存在。

2、网络分区

当网络发生异常时，分布式系统所有节点中，只有部分节点能够正常通信，而另一些节点发生异常，这个现场就是网络分区，也就是俗称的“脑裂”。极端情况下，大集群将出现小集群，这将对分布式一致性问题提出非常大的挑战。

3、三态

在分布式环境下，分布式系统的请求存在三种状态，成功、失败与超时，这与单机要么成功，要么失败的场景很不相同。而且对于超时可能有两种情况：一种是发送方没有成功将消息的发送到接收方；另一种是接收方处理之后，响应给发送方时，网络超时，发送方没有接收到响应。

4、节点故障

在分布式环境下，每一个节点都有出现宕机，假死的现象，而这也需要构建分布式系统时，需要考虑的容灾问题，也就是节点故障，不会影响这个集群的服务。

了解了分布式系统的特点和常见问题之后，在构建分布式系统时，如何合理解决这些常见问题将是各个企业所面临的挑战。假如当我们构建库存系统时，为了提升库存系统的性能，需要引入分布式缓存，这时我们需要保证缓存与数据库两个数据源中的库存数量一致，否则将出现超卖或者卖不出等数据不一致的问题。这就需要我们在更新库存数据的时候，保证缓存和数据库同步进行更新，也就是分布式事务问题。当然解决方案可以有很多种，可以只更新缓存，异步更新数据库，但要确保异步数据不丢失，否则将出现不一致；也可以同时更新缓存、数据库，让缓存和数据库一起成功或一起失败，但需要自己实现缓存的回滚。

其实，随着分布式技术的发展，有很多理论在引导着我们前进，其中CAP理论被认为是业界公认的定理。CAP理论是：一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Available）和分区容错性（P：partition tolerance）这三个基本需求，最多只能同时满足两项。所以，当系统架构师设计分布式系统时，既然无法同时满足，就需要在CAP之间做相应的权衡，以适应各种业务场景。

随着互联网系统的发展，根据实践逐渐演化出来的BASE理论，就是对CAP定理的一个权衡，即Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）：

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，但不等价于系统不可用，而是做一些可用性上的取舍。部分非重要系统功能的损失，也就是降级处理；允许响应时间在用户可接受的范围内，稍微变长；限制小部分用户的访问，绝大多数的请求不会影响，即限流。

弱状态是指分布式系统中允许存在中间状态，而这中间状态不影响系统的整体逻辑，类似于异步消息队列处理延迟，数据同步延迟等，当数据达到最终状态后，才进行处理。

最终一致性是指在分布式系统中，无法满足强一致性，对数据一致性做的一个权衡，运行系统经过一段时间后，能够达到一个一致性的状态，也就是牺牲了一定的实时性。

正式由于这些经典理论的支撑，才使得分布式技术走向今天，根据长期的探索和实践，又有一系列经典算法出现，来解决分布式系统的问题。

2PC

两阶段提交（Two-Phase Commit）是用来处理分布式事务的一种算法，用来保证分布式系统数据的一致性，也就是将分布式事务的提交分成了两个节点来进行处理。