常用架构总结

一、架构基础

1.1Master/Slave

多副本最早的是Master/Slave架构，即简单地用Slave去同步Master的数据，RocketMQ最早也是这种实现。分为同步模式（Sync Mode）和异步模式（Async Mode），区别就是Master是否等数据同步到Slave之后再返回Client。这两种方式目前在RocketMQ社区广泛使用的版本中都有支持，原理图如下图1所示。

1.2 基于Zookeeper服务

随着Google三篇核心技术论文的发表（MapReduce、GFS和BigTable），分布式领域开启了快速发展。在Hadoop 生态中，诞生了一个基于 Paxos 算法选举Leader的分布式协调服务 Zookeeper。由于Zookeeper本身拥有高可用和高可靠的特性，随之诞生了很多基于Zookeeper的高可用高可靠的系统。

Master选举是⼀个在分布式系统中⾮常常⻅的应⽤场景。分布式最核⼼的特性就是能够将具有独立计算能⼒的系统单元部署在不同的机器上，构成⼀个完整的分布式系统。⽽与此同时，实际场景中往往也需要在这些分布在不同机器上的ᇿ⽴系统单元中选出⼀个所谓的“⽼⼤”，在计算机中，我们称之为Master。

在分布式系统中，Master往往⽤来协调集群中其他系统单元，具有对分布式系统状态变更的决定权。例如，在⼀些读写分离的应⽤场景中，客户端的写请求往往是由 Master来处理的；⽽在另⼀些场景中，Master则常常负责处理⼀些复杂的逻辑，并将处理结果同步给集群中其他系统单元。Master选举可以说是ZooKeeper最典型的应⽤场景了。

ZooKeeper创建节点⼀个重要特性便是：利⽤ZooKeeper的强⼀致性，能够很好保证在分布式⾼并发情况下节点的创建⼀定能够保证全局唯⼀性，即ZooKeeper将会保证客户端⽆法重复创建⼀个已经存在的数据节点。也就是说，如果同时有多个客户端请求创建同⼀个节点，那么最终⼀定只有⼀个客户端请求能够创建成功。利⽤这个特性，就能很容易地在分布式环境中进⾏Master选举了。

1.3 基于Raft服务方式

Raft可以认为是Paxos的简化版。

Raft
Raft协议是用来解决分布式系统一致性问题的协议。
Raft协议描述的节点共有三种状态：Leader, Follower, Candidate。
term：Raft协议将时间切分为一个个的Term（任期），可以认为是一种“逻辑时间”。

选举流程：
Raft采用心跳机制触发Leader选举。系统启动后，全部节点初始化为Follower，term为0。

节点如果收到了RequestVote或者AppendEntries，就会保持自己的Follower身份。

节点如果一段时间内没收到AppendEntries消息，在该节点的超时时间内还没发现Leader，Follower就会转换成Candidate，自己开始竞选Leader。

一旦转化为Candidate，该节点立即开始下面几件事情：

• 增加自己的term。
• 启动一个新的定时器。
• 给自己投一票。
• 向所有其他节点发送RequestVote，并等待其他节点的回复。

如果在计时器超时前，节点收到多数节点的同意投票，就转换成Leader。同时向所有其他节点发送AppendEntries，告知自己成为了Leader。

每个节点在一个term内只能投一票，采取先到先得的策略，Candidate前面说到已经投给了自己，Follower会投给第一个收到RequestVote的节点。

Raft协议的定时器采取随机超时时间，这是选举Leader的关键。

在同一个term内，先转为Candidate的节点会先发起投票，从而获得多数票。

1.4 三种实现高可靠和高可用的方法优劣对比

Master/Slave
优点：实现简单
缺点：不能自动控制节点切换，一旦出了问题，需要人为介入。

Based on Zookeeper/Etcd
优点：可以自动切换节点
缺点：部署、运维、诊断成本很高。

Raft
优点：可以自己协调，并且去除依赖。
缺点：实现Raft，在编码上比较困难。

二、架构总结

2.1 zookeeper

通常在分布式系统中，构成⼀个集群的每⼀台机器都有自己的角色，最典型的集群就是Master/Slave模式（主备模式），此情况下把所有能够处理写操作的机器称为Master机器，把所有通过异步复制方式获取最新数据，并提供读服务的机器为Slave机器。

而在Zookeeper中，这些概念被颠覆了。它没有沿用传递的Master/Slave概念，而是引入了Leader、Follower、Observer三种角色。Zookeeper集群中的所有机器通过Leader选举来选定⼀台被称为Leader的机器，Leader服务器为客户端提供读和写服务，除Leader外，其他机器包括Follower和Observer,Follower和Observer都能提供读服务，唯⼀的区别在于Observer不参与Leader选举过程，不参与写操作的过半写成功策略，因此Observer可以在不影响写性能的情况下提升集群的性能。

2.1.1 ZAB协议

是⼀种特别为zookeeper专⻔设计的⼀种⽀持崩溃恢复的原⼦⼴播协议，采用⼆阶段提交。

ZAB协议包括两种基本的模式：崩溃恢复和消息广播

• 进⼊崩溃恢复模式：
  当整个服务框架启动过程中，或者是Leader服务器出现⽹络中断、崩溃退出或重启等异常情况时，ZAB协议就会进⼊崩溃恢复模式，同时选举产⽣新的Leader服务器。当选举产⽣了新的Leader服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式，其中，所谓的状态同步就是指数据同步，⽤来保证集群中过半的机器能够和Leader服务器的数据状态保持⼀致。

• 进⼊消息⼴播模式：
  当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进⼊消息⼴播模式，当⼀台同样遵守ZAB协议的服务器启动后加⼊到集群中，如果此时集群中已经存在⼀个Leader服务器在负责进⾏消息⼴播，那么加⼊的服务器就会⾃觉地进⼊数据恢复模式：找到Leader所在的服务器，并与其进⾏数据同步，然后⼀起参与到消息⼴播流程中去。Zookeeper只允许唯⼀的⼀个Leader服务器来进⾏事务请求的处理，Leader服务器在接收到客户端的事务请求后，会⽣成对应的事务提议并发起⼀轮⼴播协议，⽽如果集群中的其他机器收到客户端的事务请求后，那么这些⾮Leader服务器会⾸先将这个事务请求转发给Leader服务器。

基本特性
ZAB协议需要确保那些已经在Leader服务器上提交的事务最终被所有服务器都提交
ZAB协议需要确保丢弃那些只在Leader服务器上被提出的事务

运⾏时状态分析
在ZAB协议的设计中，每个进程都有可能处于如下三种状态之⼀

• LOOKING：Leader选举阶段。
• FOLLOWING：Follower服务器和Leader服务器保持同步状态。
• LEADING：Leader服务器作为主进程领导状态。

所有进程初始状态都是LOOKING状态，此时不存在Leader，接下来，进程会试图选举出⼀个新的Leader，之后，如果进程发现已经选举出新的Leader了，那么它就会切换到FOLLOWING状态，并开始和Leader保持同步，处于FOLLOWING状态的进程称为Follower，LEADING状态的进程称为Leader，当Leader崩溃或放弃领导地位时，其余的Follower进程就会转换到LOOKING状态开始新⼀轮的Leader选举。

⼀个Follower只能和⼀个Leader保持同步，Leader进程和所有的Follower进程之间都通过⼼跳检测机制来感知彼此的情况。若Leader能够在超时时间内正常收到⼼跳检测，那么Follower就会⼀直与该Leader保持连接，⽽如果在指定时间内Leader⽆法从过半的Follower进程那⾥接收到⼼跳检测，或者TCP连接断开，那么Leader会放弃当前周期的领导，并转换到LOOKING状态，其他的Follower也会选择放弃这个Leader，同时转换到LOOKING状态，之后会进⾏新⼀轮的Leader选举

服务器运⾏时期的Leader选举
在ZooKeeper集群正常运⾏过程中，⼀旦选出⼀个Leader，那么所有服务器的集群⻆⾊⼀般不会再发⽣变化——也就是说，Leader服务器将⼀直作为集群的Leader，即使集群中有⾮Leader机器挂了或是有新机器加⼊集群也不会影响Leader。但是⼀旦Leader所在的机器挂了，那么整个集群将暂时⽆法对外服务，⽽是进⼊新⼀轮的Leader选举。服务器运⾏期间的Leader选举和启动时期的Leader选举基本过程是⼀致的。

2.1.2 ZAB与Paxos的联系和区别

联系：

① 都存在⼀个类似于Leader进程的⻆⾊，由其负责协调多个Follower进程的运⾏。
② Leader进程都会等待超过半数的Follower做出正确的反馈后，才会将⼀个提议进⾏提交。
③ 在ZAB协议中，每个Proposal中都包含了⼀个epoch值，⽤来代表当前的Leader周期，在Paxos算法中，同样存在这样的⼀个标识，名字为Ballot。

区别：

Paxos算法中，新选举产⽣的主进程会进⾏两个阶段的⼯作，第⼀阶段称为读阶段，新的主进程和其他进程通信来收集主进程提出的提议，并将它们提交。第⼆阶段称为写阶段，当前主进程开始提出⾃⼰的提议。
　　
　　ZAB协议在Paxos基础上添加了同步阶段，此时，新的Leader会确保 存在过半的Follower已经提交了之前的Leader周期中的所有事务Proposal。这⼀同步阶段的引⼊，能够有效地保证Leader在新的周期中提出事务Proposal之前，所有的进程都已经完成了对之前所有事务Proposal的提交。
　　
　　总的来说，ZAB协议和Paxos算法的本质区别在于，两者的设计⽬标不太⼀样，ZAB协议主要⽤于构建⼀个⾼可⽤的分布式数据主备系统，⽽Paxos算法则⽤于构建⼀个分布式的⼀致性状态机系统

2.2 mysql

2.2.1 MySQL体系架构

2.2.2 MySQL运行机制

2.2.3 主从复制

主从复制实现原理