成为架构师 - 架构师训练营第 06 周



分布式数据库

MySQL 复制MySQL 主从复制

MySQL 一主多从复制



一主多从复制的优点

• 分摊负载• 专机专用• 便于冷备• 高可用

MySQL 主主复制



MySQL 主主失效恢复



MySQL 主主失效的维护过程



MySQL 复制注意事项:

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

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

• • 更新表结构会导致巨大的同步延迟。



数据分片

• 分片目标• 分片特点• 分片原理



硬编码实现数据分片



映射表外部存储



数据分片的挑战

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

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

• 无法使用数据库事务

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



分布式数据库中间件

Amoeba/Cobar 架构



Cobar 系统组件模型



如何做集群的伸缩

实践中的扩容策略



数据库部署方案 - 单一服务与单一数据库



数据库部署方案 – 主从复制实现伸缩



数据库部署方案 -两个 Web 服务及两个数据库



数据库部署方案 – 综合部署



NoSQL

CAP 原理



一致性Consistency

一致性是说，每次读取的数据都应该是最近写入的数据或者返回一个错误(Every readreceives 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

分区耐受性说，即使因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依然应该是可以操作的(The system continues to operate despite an arbitrary number ofmessages being dropped (or delayed) by the network between nodes)。



CAP 原理当网络分区失效发生的时候，我们要么取消操作，这样数据就是一致的，但是系统却不

可用;要么我们继续写入数据，但是数据的一致性就得不到保证。

对于一个分布式系统而言，网络失效一定会发生，也就是说，分区耐受性是必须要保证

的，那么在可用性和一致性上就必须二选一。

当网络分区失效，也就是网络不可用的时候，如果选择了一致性，系统就可能返回一个

错误码或者干脆超时，即系统不可用。如果选择了可用性，那么系统总是可以返回一个

数据，但是并不能保证这个数据是最新的。



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



CAP 原理与数据一致性冲突



最终一致性



最终一致写冲突

简单冲突处理策略:根据时间戳，最后写入覆盖。



客户端冲突解决

投票解决冲突(Cassandra )

Cassandra 分布式架构

Hbase 架构

Log Structed Merge Tree(LSM 树)

ACID 与 BASE



ACID

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

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

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

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



基本可用(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



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



Zab 协议



ZooKeeper 架构



搜索引擎