架构师训练营第六章总结

分布式数据库与 NOSQL

存储模型

CAP 理论

https://xie.infoq.cn/article/1954e2aa291dcd8d81b651073

BASE 理论

Basically Available(基本可用)，Soft State（软状态）和 Eventually Consistent（最终一致性）三个短语的缩写

基本可用（Basically Available）

出现了不可预知的故障，但还是能用，相比较正常的系统而言：1.响应时间损失 2.功能损失

软状态（Soft State）

相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”

允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时

最终一致性（Eventually Consistent）

上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素

ACID 强一致性模型

关系型数据库

原子性

一致性

隔离性

持久性

ZooKeeper 与 Doris

zookeeper 原理

Zookeeper 的核心是原子广播，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是恢复模式和广播模式。

　　当服务启动或者在领导者崩溃后，Zab 就进入了恢复模式，当领导者被选举出来，且大多数 server 的完成了和 leader 的状态同步以后，恢复模式就结束了。状态同步保证了 leader 和 server 具有相同的系统状态

一旦 leader 已经和多数的 follower 进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个 server 加入 zookeeper 服务中，它会在恢复模式下启动，发现 leader，并和 leader 进行状态同步。待到同步结束，它也参与消息广播。Zookeeper 服务一直维持在 Broadcast 状态，直到 leader 崩溃了或者 leader 失去了大部分的 followers 支持。

广播模式需要保证 proposal 被按顺序处理，因此 zk 采用了递增的事务 id 号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了 zxid。实现中 zxid 是一个 64 为的数字，它高 32 位是 epoch 用来标识 leader 关系是否改变，每次一个 leader 被选出来，它都会有一个新的 epoch。低 32 位是个递增计数。

当 leader 崩溃或者 leader 失去大多数的 follower，这时候 zk 进入恢复模式，恢复模式需要重新选举出一个新的 leader，让所有的 server 都恢复到一个正确的状态。　

　　 每个 Server 启动以后都询问其它的 Server 它要投票给谁。

　　 对于其他 server 的询问，server 每次根据自己的状态都回复自己推荐的 leader 的 id 和上一次处理事务的 zxid（系统启动时每个 server 都会推荐自己）

收到所有 Server 回复以后，就计算出 zxid 最大的哪个 Server，并将这个 Server 相关信息设置成下一次要投票的 Server。

　　» 计算这过程中获得票数最多的的 sever 为获胜者，如果获胜者的票数超过半数，则改 server 被选为 leader。否则，继续这个过程，直到 leader 被选举出来　　

　　» leader 就会开始等待 server 连接

　　» Follower 连接 leader，将最大的 zxid 发送给 leader

　　» Leader 根据 follower 的 zxid 确定同步点

　　» 完成同步后通知 follower 已经成为 uptodate 状态

　　» Follower 收到 uptodate 消息后，又可以重新接受 client 的请求进行服务了

Doris

分布式存储系统的高可用架构

瞬时故障

临时故障

永久故障