写点什么

架构训练营 week8 课程总结

作者:红莲疾风
  • 2022 年 2 月 04 日
  • 本文字数:2061 字

    阅读完需:约 7 分钟

  • 单机高性能网络模型

单机高性能的方式主要有四种:进程(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 的系统,它复制的是命令,而不是执行后的数据。

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


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



发布于: 刚刚阅读数: 2
用户头像

红莲疾风

关注

还未添加个人签名 2021.07.28 加入

还未添加个人简介

评论

发布
暂无评论
架构训练营 week8 课程总结