架构师训练营第六周学习总结

这周的内容主要有分布式数据库、NoSQL、Doris案例分析和ZooKeeper。其中数据库有一部分是上周的内容，这周一起总结一下。



在分布式系统中，随着需求的提升，数据库可以通过主从复制来实现读写分离。在读取压力增大时，还可以进一步采用一主多从的方法进行扩容。

但是主从复制并不能提高写入的性能，当主服务器失效时系统将无法写入数据。这时可以使用主主复制的方式增加可用性。

在主主复制模型中，如果当前主服务器失效则会切换到其他主服务器上。

不过采用主主复制只是增加了系统的可用性，不能提高对高并发的要求。为了解决高并发，可以采取业务分离，将不同的表部署在不同的节点中。



当需求进一步增加，一个节点已经无法包含一张表的内容时，就需要进行数据分片了。常见的数据分片方法有：使用客户端硬编码、建立外部映射表（存在额外数据访问及映射表本身存储困难的问题）和使用分布式数据库中间件。



分布式数据库中间件是一个打包好的工具集，向客户端提供类SQL操作的接口，在其内部实现与分布式数据库集群的交互。课程中提到，三个常见的中间件是有传承的Cobar->Amoeba->MyCat。



在分布式数据库数据迁移（扩容）时，不同于缓存，不需要使用一致性哈希。缓存使用一致性哈希的原因是为了保证较高的命中率，而数据库迁移时无论如何都需要将数据从一个节点转移到另一个节点，所以没有必要使用一致性哈希，反而由于需要逐条检查数据是否需要迁移而增加了复杂性。分布式数据库迁移的一个常用方法是采用虚拟节点，提前在一个物理节点上部署多个数据库实例作为虚拟节点，在进行迁移时选取一些虚拟节点整体迁移到新的节点上即可。



接下来时NoSQL的内容，一开始先介绍了CAP定理（CAP theorem）。说的是一致性（Consistancy）、可用性（Availability）和分区容错性（Partition tolerance）三者最多满足其二。正如作业中写道，CAP应该被称为定理而不是原理或原则或猜想，因为CAP定理已经经过严格的证明了[1]。

既然三者最多满足两点，而且分区容错性多数情况下是一定要保证的。那么就只能在一致性和可用性二选一。虽说如此，老师提到，并不是说放弃了一致性就可以获得可用性，多数情况下是二者互有妥协。



当尽量保持系统可用时，就可能会出现数据冲突的情况。为解决这种情况可以采取一些策略来保证数据的最终一致性，也就是说经过一段时间后数据是一致的。三种常见的方法为：时间戳覆盖、客户端冲突解决（如合并购物车）、投票冲突解决（Cassandra）。

之后介绍了另一种常见的分布式数据存储方案HBase。

为了使用HFile进行类数据库的操作，HBase使用了Log-structured merge-tree (LSM Tree)。由于只能在尾部进行添加操作，无论是增删改，LSM Tree都会像记录日志一样在树尾部添加节点，因此写入速度很快。在查找时，从C0开始查找然后依次查找Ci+1，这样可以保证最先查找到的数据一定是最新的。当内存中的C0达到一定规模时，C0会和C1合并，并建立新的C0。

之后提到了传统关系型数据库的ACID特性，和NoSQL与之相对的BASE特性。



之后老师着重介绍了Doris案例，这是他之前在阿里巴巴做过的项目。是经过事实验证的架构。

基本访问架构



健康检查与配置抓取

可用性、失效与恢复

集群扩容



最后介绍了分布式系统脑裂（split-brain）和其解决方案ZooKeeper。

ZooKeeper采用了简化版的Pazos算法。在同一时间只有一个节点作为Leader进行决策。当Leader节点失效时，系统会在较短时间内选出新的Leader。

Zab协议