学习笔记: 架构师训练营 - 第六周

1、分布式数据库

1.1、MySQL 主从复制

当用户的写操作到达数据库主服务器后，更新本地数据并写入 binlog 日志，而数据库从服务器通过 log 获取线程从主服务器中获取 binlog 日志并将日志存储在 Relay Log 目录下，从服务器通过 SQL 执行线程观察 log 中新的写操作命令，然后更新本地数据集

1.2、MySQL 一主多从复制

一主多从指的是一个主服务器多个从服务器，不同的从服务器可以用途不同，都只提供读操作

其优点：分摊负载、专机专用、便于冷备、高可用（部分高可用，当主服务器宕机时，可以通过从服务器读取数据，整个应用依然是不可写）

1.3、MySQL 主主复制

该情景下有两台主服务器，主服务器 A 中的数据写操作的 binlog 同步到主服务器 B 中的 RelayLog 中， 主服务器 B 写操作后 Binlog 日志会同步至主服务器 A 中的 RelayLog。

下图为主主失效恢复数据写入流程图

MySQL 复制注意事项：

• 主主复制的两个数据库不能并发写入；

• 复制只是增加了数据的读并发处理能力，没有增加写并发能力和存储能力；

• 更新表结构会导致巨大的同步延迟，一般情况下会将更新表结构相关操作禁止同步，关闭表结构变更相关的 binlog 日志，操作通常通过运维人员同时更新多个主服务器的表结构

1.4、数据分片

• 硬编码实现数据分片：将数据按照某种规则分别存储在相应的数据库中，直接在代码中以编码的方式实现，此方法实现复杂，不易管理，

• 映射表外部存储：将分区键映射成服务器编号并保存在另外一个服务器中，查询映射表获取存储数据服务器，然后向存储数据的服务器查询数据

挑战：

• 需要大量的额外代码，处理逻辑因此变得更加复杂。

• 无法执行多分片的联合查询。

• 无法使用数据库的事务。

• 随着数据的增长，如何增加更多的服务器。

1.5、分布式数据库中间件

mycat/amoeba/cobar 等都是数据库中间件，将原来的数据库分片统一在数据库中间件中处理，应用服务器连接数据库中间件，不需要连接数据库实例，也不用关心数据库是如何存储以及数据是按照何种规则进行分片。

1.6、Cobar 系统组件模型

前端通讯模块通过模拟数据库通讯协议，接收到 sql 语句后，通过 SQL 解析模块解析 SQL，将数据库分片字段以及分片字段的值解析出来，然后将解析出来的结果交给 SQL 路由模块，SQL 路由模块根据分片字段的分片规则再决定到哪台数据库服务中查询数据，使用 SQL 执行代理模块通过后端通讯模块将数据提交到相应的服务器，最终将查询的结果数据集合并，通过前端通讯模块将数据返回给应用服务器

2、数据库部署方案

2.1、单一服务与单一数据库

部署多台应用服务器连接一个单数据库，数据库单一部署

2.2、主从复制实现伸缩

2.3、两个 Web 服务及两个数据库

在服务拆分，将不同的业务模块拆分成不同模块，数据库做同样的拆分，分开部署并做主从复制

2.4、综合部署

3、NoSQL

3.1、 CAP 原理

• 一致性 Consistency：一致性是说，每次读取的数据都应该是最近写入的数据或者返回一个错误（Every read receives the most recent write or an error），而不是过期数据，也就是说，数据是一致的。

• 可用性（Availability）：可用性是说，每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不需要保证数据是最近写入的（Every request receives a (non-error) response, without the guarantee that it contains the most recent write），也就是说系统需要一直都是可以正常使用的，不会引起调用者的异常，但是并不保证响应的数据是最新的。

• 分区耐受性（ Partition tolerance）：分区耐受性说，即使因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依

当网络分区失效发生的时候，我们要么取消操作，这样数据就是一致的，但是系统却不 可用；要么我们继续写入数据，但是数据的一致性就得不到保证。

对于一个分布式系统而言，网络失效一定会发生，也就是说，分区耐受性是必须要保证 的，那么在可用性和一致性上就必须二选一。

当网络分区失效，也就是网络不可用的时候，如果选择了一致性，系统就可能返回一个 错误码或者干脆超时，即系统不可用。如果选择了可用性，那么系统总是可以返回一个 数据，但是并不能保证这个数据是最新的。

所以，关于 CAP 原理，更准确的说法是，在分布式系统必须要满足分区耐受性的前提下， 可用性和一致性无法同时满足。

3.2、CAP 原理与数据一致性冲突

针对数据一致性冲突保证数据最终一致性

3.2.1、数据最终一致性

• 根据时间戳，最后写入覆盖

• 客户端冲突解决，以购物车为例，客户端在收到多个不同的数据时将各个购物车中的数据合并成一个购物车数据

• 投票解决冲突，Cassandra 分布式架构就是采用投票的方式解决数据冲突，判断各个节点中的数据，以投出相同数据结果的节点作为最终数据

3.3、ACID 与 BASE

3.3.1、ACID

• 原子性（Atomicity）: 事务要么全部完成，要么全部取消。 如果事务崩溃，状态回到 事务之前（事务回滚）。

• 隔离性（Isolation）: 如果 2 个事务 T1 和 T2 同时运行，事务 T1 和 T2 最终的结果是 相同的，不管 T1 和 T2 谁先结束，隔离性主要依靠锁实现。

• 持久性（Durability）: 一旦事务提交，不管发生什么（崩溃或者出错），数据要保存 在数据库中。

• 一致性（Consistency）: 只有合法的数据（依照关系约束和函数约束）才能写入数据 库。

3.3.2、BASE

• 基本可用（Basically Available）系统在出现不可预知故障时，允许损失部分可用性，如 响应时间上的损失或功能上的损失。

• Soft state（弱状态）软状态，指允许系统中的数据存在中间状态，并认为该中间状态的 存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

• Eventually consistent（最终一致性）指系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态，因此最终一致性的本质是需要系统保证数据能够达到一致，而不需要实时保证系统数据的强一致性。

4、分布式一致 ZooKeeper

分布式系统脑裂：在一个分布式系统中，不同服务器获得了互相冲突的数据信息或者执行指令，导致整个 集群陷入混乱，数据损坏，被称作分布式系统脑裂

使用 zookeeper 决定使用哪个主节点作为主写入服务器节点，保证某一个时间段内只有一个主写入节点，另一个主节点做数据备份。

4.1、分布式一致性算法 Paxos

• 第一阶段：Prepare 阶段。Proposer 向 Acceptors 发出 Prepare 请求，Acceptors 针对收到的 Prepare 请求进行 Promise 承诺。

• 第二阶段：Accept 阶段。Proposer 收到多数 Acceptors 承诺的 Promise 后，向 Acceptors 发出 Propose 请求，Acceptors 针对收到的 Propose 请求进行 Accept 处理。

• 第三阶段：Learn 阶段。Proposer 在收到多数 Acceptors 的 Accept 之后，标志着本次 Accept 成功，决议形成，将形成的决议发送给所有 Learners。

Proposer 生成全局唯一且递增的 Proposal ID (可使用时间戳加 Server ID)，向所有 Acceptors 发送 Prepare 请求，这里无需携带提案内容，只携带 Proposal ID 即可。

Acceptors 收到 Prepare 和 Propose 请求后

1. 不再接受 Proposal ID 小于等于当前请求的 Prepare 请求。

2. 不再接受 Proposal ID 小于当前请求的 Propose 请求

4.2、Zab 协议

Zab 协议全称：Zookeeper Atomic Broadcast Zookeeper 原子广播

Zookeeper 是通过 Zab 协议来保证分布式事务的最终一致性。

• Zab 协议是为分布式协调服务 Zookeeper 专门设计的一种 支持崩溃恢复 的 原子广播协议 ，是 Zookeeper 保证数据一致性的核心算法。Zab 借鉴了 Paxos 算法，但又不像 Paxos 那样，是一种通用的分布式一致性算法。它是特别为 Zookeeper 设计的支持崩溃恢复的原子广播协议。

• 在 Zookeeper 中主要依赖 Zab 协议来实现数据一致性，基于该协议，zk 实现了一种主备模型（即 Leader 和 Follower 模型）的系统架构来保证集群中各个副本之间数据的一致性。

这里的主备系统架构模型，就是指只有一台客户端（Leader）负责处理外部的写事务请求，然后 Leader 客户端将数据同步到其他 Follower 节点。

Zookeeper 客户端会随机的链接到 zookeeper 集群中的一个节点，如果是读请求，就直接从当前节点中读取数据；如果是写请求，那么节点就会向 Leader 提交事务，Leader 接收到事务提交，会广播该事务，只要超过半数节点写入成功，该事务就会被提交。

Zab 协议的特性：

1）Zab 协议需要确保那些已经在 Leader 服务器上提交（Commit）的事务最终被所有的服务器提交。 2）Zab 协议需要确保丢弃那些只在 Leader 上被提出而没有被提交的事务。

Zab 协议实现的作用

1）使用一个单一的主进程（Leader）来接收并处理客户端的事务请求（也就是写请求），并采用了 Zab 的原子广播协议，将服务器数据的状态变更以 事务 proposal （事务提议）的形式广播到所有的副本（Follower）进程上去。

2）保证一个全局的变更序列被顺序引用。 Zookeeper 是一个树形结构，很多操作都要先检查才能确定是否可以执行，比如 P1 的事务 t1 可能是创建节点"/a"，t2 可能是创建节点"/a/bb"，只有先创建了父节点"/a"，才能创建子节点"/a/b"。

为了保证这一点，Zab 要保证同一个 Leader 发起的事务要按顺序被 apply，同时还要保证只有先前 Leader 的事务被 apply 之后，新选举出来的 Leader 才能再次发起事务。

3）当主进程出现异常的时候，整个 zk 集群依旧能正常工作。

Zab 协议原理

Zab 协议要求每个 Leader 都要经历三个阶段：发现，同步，广播。

• 发现：要求 zookeeper 集群必须选举出一个 Leader 进程，同时 Leader 会维护一个 Follower 可用客户端列表。将来客户端可以和这些 Follower 节点进行通信。

• 同步：Leader 要负责将本身的数据与 Follower 完成同步，做到多副本存储。这样也是提现了 CAP 中的高可用和分区容错。Follower 将队列中未处理完的请求消费完成后，写入本地事务日志中。

• 广播：Leader 可以接受客户端新的事务 Proposal 请求，将新的 Proposal 请求广播给所有的 Follower。

参考资料：Zookeeper——一致性协议:Zab 协议[https://www.jianshu.com/p/2bceacd60b8a]

5、搜索引擎

5.1、爬虫系统架构

5.2、 倒排索引

倒排索引是单词-文档举证的一种存储方式。通过倒排索引可以快速根据单词找到包含这个单词的所有文档；倒排索引主要由单词词典和倒排文件组成，单词词典存放在内存中，是组成所有文档的单词的集合，单词词典内的每条索引项记载了单词本身的一些信息和指向倒排列表的指针，通过这个指针就可以找到对应的倒排列表，而倒排列表记载了出现过某个单词的所有文档的文档列表和单词在文档中出现的位置信息，每条记录称为倒排向项。而倒排文件是倒排列表在磁盘上的物理存储

一个倒排索引由文档中所有不重复词的列表构成，对于其中每个词，有一个包含它的文档列表。为了创建倒排索引，我们首先将每个文档的 content 域拆分成单独的 词（我们称它为 词条 或 tokens ），创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文档

5.3、文档矩阵与倒排索引

5.4、Lucene 架构

Lucene 索引文件准实时更新：

索引有更新，就需要重新全量创建一个索引来替换原来的索引。这种方式在数据量很大时效率很低，并且由于创建一次索引的成本很高，性能也很差。

Lucene 中引入了段的概念，将一个索引文件拆分为多个子文件，每个子文件叫做段，每个段都是一个独立的可被搜索的数据集，索引的修改针对段进行操作。

• 新增：当有新的数据需要创建索引时，原来的段不变，选择新建一个段来存储新增的数据。

• 删除：当需要删除数据时，在索引文件新增一个 .del 的文件，用来专门存储被删除的数据 ID。当查询时，被删除的数据还是可以被查到的，只是在进行文档链表合并时，才把已经删 除的数据过滤掉。被删除的数据在进行段合并时才会被真正被移除。

• 更新：更新的操作其实就是删除和新增的组合，先在 .del 文件中记录旧数据，再在新段中添 加一条更新后的数据。

为了控制索引里段的数量，我们必须定期进行段合并操作

5.5、加权词频排序算法

6、Doris 分享

6.1、分布式存储系统的故障分类

高可用的系统需要解决在不同故障情况下都保持较高的系统可用性，但是不同故障 类型带来的问题复杂性不同，不可能使用一种解决方案处理所有情况，需要针对各种故障提供具体解决方案，先对故障进行分类，针对不同故障情况，分别处理对待

• 瞬时故障 ：引起这类故障的主要原因是网络通讯瞬时中断；服务器内存垃圾回收 或后台线程繁忙停止数据访问操作响应。其特点是故障时间短，在秒级甚至毫 秒级系统即可自行恢复正常响应。

• 临时故障 ：引起这类故障的主要原因是交换机宕机、网卡松动等导致的网络通讯 中断；系统升级、停机维护等一般运维活动引起的服务关闭；内存损坏、CPU 过热等硬件原因导致的服务器宕机；这类故障的主要特点是需要人工干预（更 换硬件、重启机器等）才能恢复正常。通常持续时间需要几十分钟甚至几小时。 故障时间可分为两个阶段：临时故障期间，临时故障恢复期间。

• 永久故障 ：引起这类故障主要原因只有一个：硬盘损坏，数据丢失。虽然损坏硬 盘和损坏内存一样，可以通过更换硬盘来重新启动机器，但是丢失的数据却永 远找不回来，因此其处理策略也和前面两种故障完全不同，恢复系统到正常状 态也需要更长的时间。故障时间可分为两个阶段：永久故障期间，永久故障恢 复期间。

6.2、故障解决方案

6.2.1、瞬时故障的高可用解决方案

瞬时故障是一种严重性较低的故障，一般系统经过较短暂的时间即可自行恢复，遇 到瞬时故障，只需要经过多次重试，就可以重新连接到服务器，正常访问。

如果应用多次重试后，仍然失败，那么有可能不是瞬时故障，而是更严重的临时故障，这时候需要执行临时故障处理策略。当然也有可能是应用服务器自己的故障，比如系统文件句柄用光导致连接不能建立等，这时候需要请求管理中心服务器进行故障仲裁，以判定故障种类。

瞬时故障，系统访问模型：

6.2.2、临时故障的高可用解决方案

临时故障要比瞬时故障严重，系统需要人工干预才能恢复正常，在故障服务器未能 恢复正常前，系统也必须保证高可用。由于数据有多份拷贝，因此读数据的时候只需要 路由选择正常服务的机器即可；写数据的时候，正常服务的机器依然正常写入，发生故 障的机器需要将数据写入到临时存储服务器，等待故障服务器恢复正常后再将临时服务 器中的数据迁移到该机器，整个集群就恢复正常了。

其中临时服务器是集群中专门部署的服务器（根据可用性规划，临时服务器也可以 部署为多台机器的集群），正常情况下，该服务器不会有数据写入，处于空闲状态，只 有在临时失效的时候，才会写入数据。任何时候该服务器都不会提供读操作服务。

临时故障发生期间，系统访问模型如图：

临时故障解决，系统恢复期间，访问模型

临时故障期间写入临时服务器的数据全部迁移到存储服务器 2 后，故障全部恢复， 存储服务器 2 恢复到正常状态，系统可按正常情况访问

6.2.3、永久故障的高可用解决方案

永久故障是指服务器上的数据永久丢失，不能恢复。由于故障服务器上的数据永久 丢失，从临时服务器迁移数据就没有意义，必须要从其他序列中正常的服务器中拷贝全 部数据才能恢复正常状态。

永久故障发生期间，由于系统无法判断该故障时临时故障还是永久故障，因此系统 访问结构和临时故障一样。当系统出现临时故障超时（超过设定时间临时故障服务器仍 旧没有启动）或者人工确认为永久故障，系统启用备用服务器替代原来永久失效的服务 器，进入永久故障恢复，其访问模型：