架构训练营 week8 课程总结

• 单机高性能网络模型

单机高性能的方式主要有四种：进程（PPC，prefork），线程（TPC，prethread），reactor，proactor。

进程和线程因为并发数较小，适合连接较少的场景。

而 reactor 和 proactor 因为可以支持海量连接，所以适合高并发的场景。

reactor 有三种落地模式

1. 单 reactor 单线程/单进程

2. 单 reactor 多线程

3. 多 reactor 多线程/多进程

其中，多 reactor 多线程/多进程是当前使用最多，且没有明显缺点的模式。

proactor 使用相对较少，因为在 Linux 上并没有得到较好的支持，并且操作系统实现复杂，程序调试复杂，而且最后也没有比 reactor 性能高多少。

• 基于 ZK 实现高可用架构

ZK 技术本质：使用原子广播，实现所有服务器的同步。使用的算法是 ZAB

ZK 的数据模型：

1. Watches

2. Data access

3. Ephemeral Nodes：临时节点。生命周期域创建节点的应用保持一致。

4. Sequence Nodes：父节点创建子节点时，序号按原子递增

ZK 的设计步骤

1. 设计节点 path

2. 选择 znode 类型

3. 设计 znode 数据

4. 设计 watch

ZK 实现集群选举，落地方案有：

1. 最小节点获胜

2. 抢建唯一节点

3. 法官判决

• 复制集群架构设计技巧

复制集群架构的例子讲了两个：Redis sentinel 和 mongoDB replication

redis sentinel 的几大功能：

1. Monitoring：监控 redis 节点状态

2. Notification：通过 API 进行集群状态通知

3. Automatic failover：实现故障自动切换

4. Configuration provider：为 client 提供 master 的最新地址

选举算法是 raft 算法

redis sentinel 是独立运行的程序，代码跟 redis 是一起的，只是启动的时候，单独配置之后，就成了 sentinel

架构模式有三种：双节点，三节点，分离部署。

其中双节点一般不会使用，因为很容易引起脑裂。三节点和分离部署在配置合理的情况下可以解决脑裂的问题。

mongoDB replication 的基本实现

1. primary 处理所有 write 请求，secondary 可以 read 或者仅仅复制数据

2. 异步复制，复制 oplog

3. 选举算法在 3.2 前是 bully，3.2 之后是 raft

4. 最多 50 个节点，并且只有 7 个节点可以参与选举。

节点同步流程：

1. 寻找同步源

2. 全量复制

3. 增量复制

架构技巧

1. read preference：同步源未必是 primary，可以自己配置

2. arbiter：仲裁节点，只是投票，不会复制数据。可以防止脑裂的情况出现。

• 分片集群架构设计技巧

介绍了四种分片集群架构设计

第一种：ES

节点有三种类型：1. master 2. data 3.coordinating

每个分片都可以有多个副本，保证高可用

选举算法在 7.0 以前用 bully，7.0 以后用 raft

部署模式有 4 种：

1. master/data 混合部署，适合数据量不大的系统

2. master 和 data 分离部署，适合业务量较大的系统，这个也是应用最多的模式

3. coordinating 分离部署，适合数据量较大，切读写请求较为复杂的业务。

4. corss cluster replication，适合全球性业务，或者分区业务。

第二种：redis cluster

所有的 key 按照 hash 算法分成 16384 个槽位，按槽位分配给相应的分片节点。

节点之间通过 gossip 算法交换信息，节点变化会通知所有的分片更新信息

每个节点有所有 key 的分布信息

client 请求任意节点，如果节点发现请求的数据不是自己的，会用 move 命令让 client 请求相应的分片

第三种：mongo sharding

mongo sharding 的分片角色有三种：mongos；config server；shard

mongos 主要是代理程序，接受应用请求，可以和应用程序部署到一起，也可以和 shard 服务部署到一起。并且会缓存 config server 的配置信息。

config server 是存储集群元数据的角色。自身通过 replica set 保证高可用

这个角色挂掉的时候，cluster 进入 read only

shard 存储分片的服务器

自身通过 replica set 保证高可用

replica set 全部挂掉以后，分片就无法访问了。

第四种：HDFS

主要有四种角色：NameNode，DataNode，JournalNode，FailoverController

NameNode 是集群管理节点，保存集群元数据

DataNode 存储实际数据

JournalNode 感觉比较鸡肋，主要是 NameNode 修改集群状态后，写日志；standBy NameNode 监听它，并且拉取日志。其实它的效果与 ZooKeeper 类似。

Failover Controller 其实是 NameNode 节点内的独立进程。监控 NameNode 的状态，依赖 ZooKeeper 可以做高可用。（结果到了最后还是要依赖 ZK）

• 常见集群算法解析

主要讲了 3 种算法：

第一种：gossip 算法，这个是 redis cluster 同步分片的算法。

其优点是：

1. 扩展性好，网络节点可以任意修改和增加

2. 去中心化，容错性好

缺点是：

1. 需要花费一定时间才能达到最终一致性

2. 消息冗余，因为发给其他节点的消息可能再发回来

3. 不适合超大规模集群

4. 可能出现恶意节点传播垃圾信息（在外网落地的场景下）

落地模式有三种：

1. direct Mail

2. anti Entropy

3. rumor mongering

第二种：bully 算法

简单粗暴：进程发现协调者不响应了，就觉得它应该挂了，要选举；选的协调者是当前节点中进程号最大/最小的。

第三种：Raft 算法

raft 算法主要是因为 paxos 太复杂了，而被设计出来的一种算法。

角色有三种：

1. Follower，相当于 slave，从节点

2. Leader，主节点，也就是 master

3. Candidate，候选者，就是 Follower 中想要成为 leader 的节点。

raft 算法实际上是一种 state machine replication 的系统，它复制的是命令，而不是执行后的数据。

每个读写命令都要节点进行投票进行一致性处理，所以可以解决非拜占庭错误。

非拜占庭错误，简单说就是在系统内有故障或者木马等存在的情况下，系统依然可以纠错的特性。