下载掌阅APP，畅读海量书库
立即打开
分布式数据库的运行依赖网络互联，单机数据库只运行在单独的操作系统上，不会涉及网络互联。本节介绍的分布式理论（CAP理论、BASE理论）和一致性算法相关的内容是围绕如何在网络异常的情况下，最大限度地保证数据一致性而展开的。
分布式数据库是分布式系统，所以必须遵循CAP理论。CAP理论又被称作布鲁尔定理，如图2-1所示，它指出一个分布式系统不可能同时满足以下3点。
● 一致性（consistency，C）。
● 可用性（availability，A）。
● 分区容错性（partition tolerance，P）。
图2-1 CAP理论
要理解CAP理论，理解“分区容错性”是关键。分布式系统里的网络异常是不可避免的，在异常发生以后网络分区就客观存在了，对分区是必须要容忍的。在这样的情况下，系统设计人员必须在一致性和可用性之间做出选择，也就是一致性和可用性（CA）不能兼顾。可以选择停掉系统，等网络节点恢复后修复数据库，这样就保证了一致性和分区容错性（CP）；也可以选择继续提供服务，放弃强一致性的要求，这样就保证了可用性和分区容错性（AP）。换句话说，要么牺牲一致性，要么牺牲可用性。
CAP理论起源于美国加利福尼亚大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在2000年的分布式计算原理研讨会上提出的一个猜想
。2002年，美国麻省理工学院的赛思·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了布鲁尔猜想的证明论文，使之成为一个理论。
论文里面说明了C、A、P三者不能同时满足。但是如上文所述，P在分布式系统里客观存在，所以只要对C和A做正确的取舍即可。
BASE是指基本可用（basically available，BA）、软状态（soft state，S）、最终一致性（eventual consistency，E）。基于传统ACID（atomicity，原子性；consistency，一致性；isolation，隔离性；durability，持久性）方法论设计的关系数据库，会把一致性的实现作为首要考虑内容，但是基于BASE理论的方法论是弱一致性的策略。
BASE理论
最早在网络领域提出，为非关系型数据库而设计。BASE理论的一致性模型和ACID理论的相比是弱一致性模型，在KV数据库和文档数据库里面应用较多。
BASE理论和ACID理论的对比这里就不详细介绍了，感兴趣的读者可以自行查阅文献。总体来说，BASE理论是CAP理论的补充，如果一致性在当前不能被满足，可以放宽约束条件，同时保证对外服务的可用性（BA）。系统里的所有数据副本在经过一段时间的同步后，最终实现一致性（E）。从最开始到最后实现一致性的过程中，存在软状态（S）。
一致性算法
有很多，本节只简单介绍2PC、3PC、Paxos、Raft、ZAB这几种。生产系统里常用的软件大都实现并改进了这些一致性算法。
2PC（two phase commit，两阶段提交）是使分布式系统的所有工作实例，在事务提交时保持一致性而设计的一种算法。很多分布式数据库都是使用2PC作为提交协议算法的，比如Greenplum、Google Spanner。提交的受众有两个角色：参与者和协调者。
第一阶段，协调者记录本地日志信息，发送询问给各个参与者，然后等待；参与者回复自己是否可以提交，如果可以提交，参与者也记录本地日志。
第二阶段，如果协调者收到所有参与者的确认信息，则记录本地提交日志，然后给各个参与者发送提交信息，参与者收到后记录本地提交日志，返回确认信息给协调者；如果协调者收到任何一个参与者的中止信息，则会记录本地中止日志，然后给各个参与者发送中止信息，参与者收到后记录本地中止日志，然后发送确认信息给协调者。
2PC算法的优点是原理简单、清晰，实现方便。缺点也很明显：协调者有单点故障；第二阶段不能保证强一致性，数据会不一致；参与者需要相互等候，同步阻塞。两阶段提交协议是本书的重点，在后续的源码分析章节里有详细的状态机描述和代码分析内容，读者可以学习到一个工业级软件Greenplum是如何改进和实现2PC的，以及各种异常情况的处理方法。
3PC算法基于2PC算法改造和升级而来。它引入了超时机制，并将2PC算法的第一阶段分成了两个阶段，所以一共有3个阶段：准备阶段、预提交阶段、提交阶段。参与者收到预提交请求后不做实际动作，进入预提交阶段，收到提交请求或者超时以后才完成实际操作，进入提交阶段。3PC算法的优点很明显，即在出现协调者单点故障的时候参与者也能自己进行提交。当然，如果这时候出现了网络分区，数据还是会不一致。
Paxos
是一个强一致性算法，也是一个多数派算法。集群里面出现分歧的时候，每个节点都可以提出修改该条数据的提案，提案能否通过取决于是否有超过半数的节点同意该提案。按照Paxos算法策略，集群的节点有以下多种角色。
● 客户端（client）：向分布式数据库发起请求的节点。
● 提案者（proposer）：向集群里面其他节点发起提案的节点。
● 接收者（acceptor/voter）：接收某个提案者的提案的节点。
● 学习者（learner）：提案通过后，进行数据复制的节点。
● 领导者（leader）：提案通过后，被选为领导者的节点。Paxos算法确保只有一个领导者。
Paxos算法在具体实施的时候又分为很多种，如Basic Paxos、Multi-Paxos、Cheap Paxos、Fast Paxos、Byzantine Paxos，还有一些是几种算法的综合变体。
Raft
也是一个强一致性算法，通过选举的方式选出领导者，然后进行日志处理。所以主要有两个阶段，第一阶段是领导者选举，第二阶段是日志复制。按照这样的逻辑，节点也有多种角色。
● 客户端（client）：向分布式数据库发起请求的节点。
● 候选人（candidate）：在领导者被选出来以前，各个节点都是候选人。
● 领导者（leader）：在选举结束以后，被选为领导者的候选人。只有领导者才能进行日志复制工作。它从客户端接收请求，在本地做完日志复制以后，再将日志发散到各个跟随者节点上。
● 跟随者（follower）：跟随者在接收到来自领导者的日志信息后，进行本机的日志复制。
Raft算法还有一个安全（safty）机制，保证了选举和日志复制过程中遇到异常也不会破坏强一致性。Raft算法的选举策略和Paxos算法的类似，利用多数原则来确定完成投票。
Zab是Zookeeper Atomic Broadcast（Zookeeper原子广播）的缩写，是在ZooKeeper产品里面使用的算法。Zookeeper有跟随者和领导者两个角色，跟随者向领导者发起事务提交请求，领导者接收事务提交请求，用Zab算法将数据广播到各个节点上。Zookeeper的数据按照一个树形结构存储。这时候Zab算法也要保证事务提交的顺序正确和异常处理正确等。
提示 本节简单介绍了几种一致性算法。2PC算法和3PC算法要求所有节点提交成功，而Paxos算法、Raft算法等只需要一半以上的节点提交成功，在算法策略上有本质差异。
数据处理技术和数据库技术相辅相成，像OLTP、OLAP（online analytical processing，联机分析处理）和HTAP（hybrid transaction/analytical processing，在线事务与在线分析综合处理）这样的技术属于数据处理技术。数据可以被各种软件处理，如Elasticsearch、Splunk、Hadoop、Solr/Lucene，也可以被数据库处理。所以，对应不同场景的数据库可以分别将其称为OLTP型数据库、OLAP型数据库、HTAP型数据库。
OLTP型数据库即联机事务处理型数据库，强调速度和并发度。通常是高可用的在线系统，以简单查询为主，力求速度快、并发度高，以银行、证券的实时交易系统为主要应用场景。
为了达到速度快的目的，OLTP型数据库通常会使用缓存、索引等技术，对频繁访问的表或者对象进行预操作。分布式技术也给OLTP型数据库的发展带来了积极的影响，比较有名的产品如Google Spanner、AWS Aurora等，也有用MariaDB的集群方式部署的OLTP型数据库。
OLAP型数据库即联机分析处理型数据库，强调数据量大和查询条件复杂。这样的数据库通常运行在后台的数据挖掘系统中。OLAP型数据库的速度和并发度与OLTP型数据库相比要低很多，该类型数据库在报表报告的生成、科学计算、商业智能领域使用广泛。
OLAP型数据库的显著特点是查询条件复杂、查询维度多、数据量大、并发度低。本书介绍的Greenplum利用分布式技术将复杂的大型查询分解，按照数据分布的特点在各个子节点上进行数据读入和部分聚合，然后进行总体聚合并返回结果。这就是典型的利用分布式技术来处理复杂查询和大量数据的例子。同时，物化视图、位图索引等技术也能帮助提高OLAP型数据库的性能。
HTAP型数据库是Gartner公司提出的。它把OLTP型数据库和OLAP型数据库整合到一起，目标是为实时、高效查询提供数据库支持。有时候大家会把使用了新技术的数据库归类为HTAP型数据库，比如内存数据库、云原生数据库等。虽然目前HTAP型数据库的划定界限还比较模糊，但是越来越多的OLTP和OLAP型数据库在向HTAP领域发展。比如MariaDB、Microsoft的Cosmos DB、PingCAP的TiDB、SAP的HANA等。本书着重介绍的Greenplum数据库也在向HTAP领域做优化和扩展。