架构师训练营 -week06- 总结

本周重点学习了以下几个方面的内容：

• CAP原理、分布式关系数据库相关知识

• Zookeeper分布式一致性架构、搜索引擎基本架构知识

1. CAP原理：

CAP 定理（CAP theorem）又被称作布鲁尔定理（Brewer's theorem），是加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在 2000 年的 ACM PODC 上提出的一个猜想。2002 年，麻省理工学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了布鲁尔猜想的证明，使之成为分布式计算领域公认的一个定理。对于设计分布式系统的架构师来说，CAP 是必须掌握的理论。



CAP的理论也经历了演化，在第二版本的翻译内容如下：

在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。



重点解读：

1. 分布式系统并不一定都会互联和共享数（例如memcache集群之间是不会通信的），所以CAP针对的是interconnected 和 share data的系统。

2. CAP 关注的是对数据的读写操作，而不是分布式系统的所有功能

• 一致性（Consistency）

第一版解释：所有节点在同一时刻都能看到相同的数据。

第二版解释：对某个指定的客户端来说，读操作保证能够返回最新的写操作结果。

第一版解释和第二版解释的主要差异点表现在：第一版从节点 node 的角度描述，第二版从客户端 client 的角度描述。

相比来看，第二版更加符合我们观察和评估系统的方式，即站在客户端的角度来观察系统的行为和特征。



• 可用性（Availability）

第一版解释：每个请求都能得到成功或者失败的响应。

第二版解释：非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）。



• 分区容忍性（Partition Tolerance）

第一版解释：出现消息丢失或者分区错误时系统能够继续运行。

第二版解释：当出现网络分区后，系统能够继续“履行职责”。

第一版强调“运行”，只要系统不宕机，我们都可以说系统在运行，返回错误也是运行，拒绝服务也是运行；而 第二版强调“履行职责”，这点和可用性是一脉相承的。也就是说，只有返回 reasonable response 才是 function。相比之下，第二版解释更加明确。



下面引用了一些关于CAP坑点的讨论：

1、适用场景。分布式系统有很多类型，有异构的，比如节点之间是上下游依赖的关系，有同构的，比如分区/分片型的、副本型的（主从、多主）。CAP定理的适用场景是副本型的这种。

2、一致性的概念，从强到弱，线性一致性、顺序一致性、因果一致性、单调一致性、最终一致性，CAP中的一致性应该是指顺序一致性。

3、CAP中的一致性，与ACID中的一致性的区别。事务中的一致性，是指满足完整性约束条件，CAP中的一致性，是指读写一致性。

4、CAP中的可用性，与我们常说的高可用的区别。比如HBase、MongoDB属于CP架构，Cassandra、CounchDB属于AP系统，能说后者比前者更高可用么？应该不是。CAP中的可用性，是指在某一次读操作中，即便发现不一致，也要返回响应，即在合理时间内返回合理响应。我们常说的高可用，是指部分实例挂了，能自动摘除，并由其它实例继续提供服务，关键是冗余。

5、哪些情况属于网络分区。网络故障造成的分区，属于。节点应用出现问题导致超时，属于。节点宕机或硬件故障，不属于。



还有关于CAP 的具体细节：

• 1. CAP 关注的粒度是数据，而不是整个系统。

CAP 理论的定义和解释中，用的都是 system、node 这类系统级的概念，这就给很多人造成了很大的误导，认为我们在进行架构设计时，整个系统要么选择 CP，要么选择 AP。但在实际设计过程中，每个系统不可能只处理一种数据，而是包含多种类型的数据，有的数据必须选择 CP，有的数据必须选择 AP。而如果我们做设计时，从整个系统的角度去选择 CP 还是 AP，就会发现顾此失彼，无论怎么做都是有问题的。

所以在 CAP 理论落地实践时，我们需要将系统内的数据按照不同的应用场景和要求进行分类，每类数据选择不同的策略（CP 还是 AP），而不是直接限定整个系统所有数据都是同一策略。



• 2. CAP 是忽略网络延迟的。



• 3. 正常运行情况下，不存在 CP 和 AP 的选择，可以同时满足 CA。

CAP 理论告诉我们分布式系统只能选择 CP 或者 AP，但其实这里的前提是系统发生了“分区”现象。如果系统没有发生分区现象，也就是说 P 不存在的时候（节点间的网络连接一切正常），我们没有必要放弃 C 或者 A，应该 C 和 A 都可以保证，这就要求架构设计的时候既要考虑分区发生时选择 CP 还是 AP，也要考虑分区没有发生时如何保证 CA。



• 4. 放弃并不等于什么都不做，需要为分区恢复后做准备。

CAP 理论告诉我们三者只能取两个，需要“牺牲”（sacrificed）另外一个，这里的“牺牲”是有一定误导作用的，因为“牺牲”让很多人理解成什么都不做。实际上，CAP 理论的“牺牲”只是说在分区过程中我们无法保证 C 或者 A，但并不意味着什么都不做。因为在系统整个运行周期中，大部分时间都是正常的，发生分区现象的时间并不长。例如，99.99% 可用性（俗称 4 个 9）的系统，一年运行下来，不可用的时间只有 50 分钟；99.999%（俗称 5 个 9）可用性的系统，一年运行下来，不可用的时间只有 5 分钟。分区期间放弃 C 或者 A，并不意味着永远放弃 C 和 A，我们可以在分区期间进行一些操作，从而让分区故障解决后，系统能够重新达到 CA 的状态。



除了CAP理论，还有CAP和BASE理论

• ACID

ACID 是数据库管理系统为了保证事务的正确性而提出来的一个理论，ACID 包含四个约束：

1.Atomicity（原子性）一个事务中的所有操作，要么全部完成，要么全部不完成，不会在中间某个环节结束。事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样。

2.Consistency（一致性）在事务开始之前和事务结束以后，数据库的完整性没有被破坏。

3.Isolation（隔离性）数据库允许多个并发事务同时对数据进行读写和修改的能力。隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。

事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。

4.Durability（持久性）事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

可以看到，ACID 中的 A（Atomicity）和 CAP 中的 A（Availability）意义完全不同，而 ACID 中的 C 和 CAP 中的 C 名称虽然都是一致性，但含义也完全不一样。ACID 中的 C 是指数据库的数据完整性，而 CAP 中的 C 是指分布式节点中的数据一致性。再结合 ACID 的应用场景是数据库事务，CAP 关注的是分布式系统数据读写这个差异点来看，其实 CAP 和 ACID 的对比就类似关公战秦琼，虽然关公和秦琼都是武将，但其实没有太多可比性。



• BASE

BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency），核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。



BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。前面在剖析 CAP 理论时，提到了其实和 BASE 相关的两点：

• CAP 理论是忽略延时的，而实际应用中延时是无法避免的。

• AP 方案中牺牲一致性只是指分区期间，而不是永远放弃一致性。



ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。



以上内容参考出处：https://time.geekbang.org/column/article/9302



2. 分布式关系数据库：

分布式关系数据库有两种概念：

• 第一种是从数据库本身就是支持分布式结构的产品

一般是这么定义的：分布式数据库是服务于写多读少、低延时、海量并发 OLTP 场景的，具备海量数据存储能力和高可靠性的关系型数据库。

代表产品有：TiDB、阿里的OceanBase、腾讯的TDSql等。



• 第二种是从传统的单体数据库（例如MySQL）通过代码、中间件、或者服务化的改造，支持分布式系统场景下的数据库解决方案。

主要有下面几种：

• 1. 客户端组件 + 单体数据库

通过独立的逻辑层建立数据分片和路由规则，实现单体数据库的初步管理，使应用能够对接多个单体数据库，实现并发、存储能力的扩展。其作为应用系统的一部分，对业务侵入比较深。

这种客户端组件的典型产品是 Sharding-JDBC。



• 2. 代理中间件 + 单体数据库

以独立中间件的方式，管理数据规则和路由规则，以独立进程存在，与业务应用层和单体数据库相隔离，减少了对应用的影响。随着代理中间件的发展，还会衍生出部分分布式事务处理能力。

这种中间件的典型产品是 MyCat。



• 3. 单元化架构 + 单体数据库

单元化架构是对业务应用系统的彻底重构，应用系统被拆分成若干实例，配置独立的单体数据库，让每个实例管理一定范围的数据。例如对于银行贷款系统，可以为每个支行搭建独立的应用实例，管理支行各自的用户，当出现跨支行业务时，由应用层代码通过分布式事务组件保证事务的 ACID 特性。



根据不同的分布式事务模型，应用系统要配合改造，复杂性也相应增加。例如 TCC 模型下，应用必须能够提供幂等操作。在分布式数据库出现前，一些头部互联网公司使用过这种架构风格，该方案的应用系统的改造量最大，实施难度也最高。



3. Zookeeper

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务。它提供了很多基本的操作，能实现什么样的功能更多取决于使用者如何来使用它。

• ZooKeeper 作为一个分布式的协调服务框架，主要用来解决分布式集群中，应用系统需要面对的各种通用的一致性问题。ZooKeeper 本身可以部署为一个集群，集群的各个节点之间可以通过选举来产生一个 Leader，选举遵循半数以上的原则，所以一般集群需要部署奇数个节点。

• ZooKeeper 最核心的功能是，它提供了一个分布式的存储系统，数据的组织方式类似于 UNIX 文件系统的树形结构。由于这是一个可以保证一致性的存储系统，所以你可以放心地在你的应用集群中读写 ZooKeeper 的数据，而不用担心数据一致性的问题。分布式系统中一些需要整个集群所有节点都访问的元数据，比如集群节点信息、公共配置信息等，特别适合保存在 ZooKeeper 中。

• ZooKeeper 还提供了一种订阅 ZNode 状态变化的通知机制：Watcher，一旦 ZNode 或者它的子节点状态发生了变化，订阅的客户端会立即收到通知。

利用 ZooKeeper 临时节点和 Watcher 机制，我们很容易随时来获取业务集群中每个节点的存活状态，并且可以监控业务集群的节点变化情况，当有节点上下线时，都可以收到来自 ZooKeeper 的通知。

• 此外，我们还可以用 ZooKeeper 来实现业务集群的快速选举、节点间的简单通信、分布式锁等很多功能。



Zookeeper 特点

• 一致性：客户端无论连接到集群中的哪个节点，读到的数据都是一样的。

• 实时性：ZooKeeper 保证客户端在一定的时间间隔内获得结果，包括成功和失败。但由于网络延迟原因，ZooKeeper 不能保证两台客户端同时得到刚更新的消息。如果都需要最新的消息，就需要调用 sync() 接口。

• 原子性：领导者在同步数据时会保证事务性，要么都成功，要么都失败。

• 顺序性：一台服务器上如果消息 a 在消息 b 前发布，那么所有服务器上的消息 a 都是在消息 b 前发布的。



• Zookeeper 如何保证数据一致性

ZooKeeper 通过 ZAB 协议来进行 ZooKeeper 集群间的数据同步，保证数据的一致性。



• ZooKeeper 集群架构与读写机制

在 ZooKeeper 集群中，服务器角色分为领导者（leader）和学习者（learner），后者又分为观察者（observer）和跟随者（follower），具体功能如下：

• 领导者：为客户端提供读写功能，负责投票的发起和决议。集群中只有领导者才能接受写服务。

• 跟随者：为客户端提供读服务，如果是写服务则转发给领导者。跟随者在选举过程中进行投票。

• 观察者：为客户端提供读服务，如果是写服务就转发给领导者。观察者不参与领导者的选举投票，也不参与写的过半原则机制。

此外，还有一个独立于 Zookeeper 集群的角色：客户端（client），是连接 Zookeeper 集群的使用者、请求的发起者。一个 ZooKeeper 集群可能会有多个客户端，客户端能任意连接其中一台 ZooKeeper 节点，并读取数据，但所有的客户端都只能向领导者节点去写数据。



在 ZooKeeper 的选举中，如果过半的节点都选一个节点作为领导者，那么这个节点就会是领导者节点。正因如此，在 ZooKeeper 集群中，只要有过半的节点是存活的，那么这个 ZooKeeper 就可以正常提供服务。所以在搭建 ZooKeeper 集群时，通常会使用奇数台，这样做比较节约机器。比如安装一个 6 台的 ZooKeeper 集群，如果其中 3 台宕机，就会导致集群不可用。以这样的情况来看，安装 6 台和安装 5 台的效果是一样的，所以安装 5 台比较合适。