第六周作业 2

本周主要学习了分布式数据库的相关知识。

分布式关系数据库

MySQL 主从复制

1. 用户发起命令，更新主服务器，并保存命令到 Binlog，

2. 从服务器 Log 获取线程，从 Master 读取命令，放到 Relay Log 中，从服务器的 SQL 执行线程观察 Relay Log，读取新命令并执行。保持主从数据的一致。Relay Log 和 Binlog 中以序列号给每个命令顺序编号。

通常实际中都是一主多从的架构，不同的从库处理担任不同的角色，如：分摊负载（读写分离）、专机专用（备份、数据分析库）、便于冷备、部分高可用

MySQL 主主复制

主从架构存在主服务器发生单点故障的风险，从库切换成主库需要作改动。双主增加写入口，增加了系统的高可用。

与主从不一样的是，任何主服务器的更新命令会保存到服务器的 Binlog 并同步到其他服务器的 Relay Log 中。通常主主复制的主服务器 会通常是一个 主从的集群。

MySQL 复制注意事项

• 不能向两个服务器同时写，避免数据冲突

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

• 更新表结构会导致巨大的同步延迟（运维人工修改表结构）

数据分片

主主架构的写性能还是存在瓶颈，这时需要将写分摊到更多的服务器。

分片目标：把大表拆分成多个小表，放到不同的服务器。提升并发处理能力。

分片实现：

• 硬编码实现数据分片。应用代码将分片 key 影射到不同服务器编号。这种方式 影响应用程序，不容易管理。

• 影射表。应用代码将分区键影射成服务器编号。提升一定的伸缩性。

• 分布式数据库中间件。（解决前面两种方式的：需要大量额外的代码，处理逻辑变得复杂； 无法执行多分片的联合查询；如何伸缩）

分布式数据库中间件有：Mycat、Cobar

伸缩方法：

分布式关系型数据库伸缩一定需要数据迁移。为了做服务伸缩，需要最开始就规划一个比较大的服务器数量，开始是将不同的服务器对应一个连接，后台将连接拆到不同真正服务器。后面扩展时：

1. 增加扩容服务器

2. 将原服务器部分实例与扩容服务器做主从配置，将需要迁移的数据库复制到扩容服务器

3. 等原服务器实例的数据全部迁移到扩容服务器，更改服务器配置



CAP 原理与 NoSQL 数据库架构

CAP 原理

CAP 原理是指在一个分布式系统中，CAP 三个特性不可能同时达到，要么接受数据不一致，要么接受数据不可用。

C 代表 Consistency (一致性)。每次读取的数据都应该是最近写入的数据或者返回一个错误，而不是过期的数据。也就是说数据是一致的。

A 代表 Availability（可用性）。每次请求都应该得到一个响应，而不是返回一个错误或失去响应。不过这个响应不需要保证数据是最近写入的，也就是说系统需要一直都能正常使用，不会引起调用者异常，但不保证响应的数据是最新的。

P 代表 Partition tolerance（分区耐受性）。即使因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统仍然需要是可以操作的。

ACID

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

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

持久性（Durability）：一旦事务提交，不管发生了什么，数据要保存在数据库中

一致性（Consistency）：只有合法的数据才能写入数据库？



放弃了强一致性，只需要达到最终一致性。当网络延迟恢复、数据同步完成时，最终不同节点服务器是一致的。

最终一致性冲突解决方法

• 根据时间戳，最后写入覆盖前面的写入。

• 客户端冲突解决。将两个数据返回给客户端，让用户根据业务逻辑自己决定怎么保存数据。

• 投票解决冲突（Cassandra）

BASE

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

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

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

ZooKeeper 与分布式一致性架构

难点：高可用下做到数据一致性

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

分布式一致性算法 Paxos

三个角色：Proposer, Acceptor, Learner

• 第一阶段：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 请求后：

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

• 不再接受 Proposal ID 小于等于当前请求的 Propose 请求。

缺点：复杂。

Zab 协议

简化的 Paxos，ZooKeeper 使用 Zab 协议

集群有三种角色：

• leader 就是我们说的主；

• follower 就是我们说的从；

• observer 可以认为是主的clone copy，不参与投票，

Doris 案例

大家都是做业务开发，如果想去做更难技术，需要自己去争取，发现公司当前技术方案存在的问题，业务需要，并提出新方案，说服业务方、技术决策者。

分布式非关系型数据库的难点：

1. 负载均衡。通过虚拟节点将key尽可能均衡的分布到集群的机器。

2. 伸缩。通过虚拟节点和机器的影射，将不同的虚拟节点伸缩到不同的机器。需要考虑数据的复制。如果虚拟节点的数据存放在一个文件，通过文件的复制是最快速的方法。

3. 高可用。构建集群，数据写多份，查一份。

4. 失效处理。失效时，只写、读正常的服务，备份库记录失效期间写命令，恢复时将备份库写命令重写到失效库中。