你管这破玩意儿叫高可用（二）

Cluster 分片集群
主从模式看似完美，但存在以下几个问题

1. 主节点写的压力难以降低：因为只有一个主节点能接收写请求，如果在高并发的情况下，写请求如果很高的话可能会把主节点的网卡打满，造成主节点对外无法服务
2. 主节点的存储能力受到单机存储容量的限制：因为不管是主节点还是从节点，存储的都是全量缓存数据，那么随着业务量的增长，缓存数据很可能直线上升，直到达到存储瓶颈
3. 同步风暴：因为数据都是从 master 同步到 slave 的，如果有多个从节点的话，master 节点的压力会很大
   为了解决主从模式的以上问题，分片集群应运而生，所谓分片集群即将数据分片，每一个分片数据由相应的主节点负责读写，这样的话就有多个主节点来分担写的压力，并且每个节点只存储部分数据，也就解决了单机存储瓶颈的问题，但需要注意的是每个主节点都存在单点问题，所以需要针对每个主节点做高可用，整体架构如下

 
原理也很简单，在 Proxy 收到 client 执行的 redis 的读写命令后，首先会对 key 进行计算得出一个值，如果这个值落在相应 master 负责的数值范围（一般将每个数字称为槽，Redis 一共有 16384 个槽）之内，那就把这条 redis 命令发给对应的 master 去执行，可以看到每个 master 节点只负责处理一部分的 redis 数据，同时为了避免每个 master 的单点问题，也为其配备了多个从节点以组成集群，当主节点宕机时，集群会通过 Raft 算法来从从节点中选举出一个主节点

ES
再来看一下 ES 是如何实现高可用的，在 ES 中，数据是以分片（Shard）的形式存在的，如下图所示，一个节点中索引数据共分为三个分片存储

 
但只有一个节点的话，显然存在和 Redis 的主从架构一样的单点问题，这个节点挂了，ES 也就挂了，所以显然需要创建多个节点

 
一旦创建了多个节点，分片（图中 P 为主分片，R 为副本分片）的优势就体现出来了，可以将分片数据分布式存储到其它节点上，极大提升了数据的水平扩展能力，同时每个节点都能承担读写请求，采用负载均衡的形式避免了单点的读写压力

ES 的写机制与 Redis 和 MySQL 的主从架构有些差别（后两者的写都是直接向 master 节点发起写请求，而 ES 则不是），所以这里稍微解释一下 ES 的工作原理

首先说下节点的工作机制，节点（Node）分为主节点（Master Node）和从结点（Slave Node），主节点的主要职责是负责集群层面的相关操作，管理集群变更，如创建或删除索引，跟踪哪些节点是集群的一部分，并决定哪些分片分配给相关的节点，主节点也只有一个，一般通过类 Bully 算法来选举出来，如果主节点不可用了，则其他从节点也可以通过此算法来选举以实现集群的高可用，任何节点都可以接收读写请求以达到负载均衡的目的

再说一下分片的工作原理，分片分为主分片（Primary Shard，即图中 P0，P1，P2）和副本分片（Replica Shard，即图中 R0，R1，R2），主分片负责数据的写操作，所以虽然任何节点可以接收读写请求，但如果此节点接收的是写请求并且没有写数据所在的主分片话，此节点会将写请求调度到主分片所在的节点上，写入主分片后，主分片再把数据复制到其他节点的副本分片上，以有两个副本的集群为例，写操作如下

 
MQ
ES 利用数据分片来提升高可用和水平扩展能力的思想也应用在其他组件的架构设计上，我们以 MQ 中的 Kafka 为例再来看下数据分片的应用

 Kafka 高可用设计，图片来自《武哥漫谈IT》

如上是 Kafka 集群，可以看到每个 Topic 的 Partition 都分布式存储在其它消息服务器上，这样一旦某个 Partition 不可用，可以从 follower 中选举出 leader 继续服务，不过与 ES 中的数据分片不同的是，follower Partition 属于冷备，也就是说在正常情况下不会对外服务，只有在 leader 挂掉之后从 follower 中选举出 leader 后它才能对外提供服务

存储层
接下来我们再来看一下最后一层，存储层（DB），这里我们以 MySQL 为例来简单地讨论一下其高可用设计，其实大家如果看完了以上的高可用设计，会发现 MySQL 的高可用也不过如此，思想都是类似的，与 Redis 类似，它也分主从和分片（即我们常说的分库分表）两种架构

主从的话与 LVS 类似，一般使用 keepalived 的形式来实现高可用，如下所示

 
如果 master 宕机了，Keepalived 也会及时发现，于是从库会升级主库，并且 VIP 也会“漂移”到原从库上生效，所以说大家在工程配置的 MySQL 地址一般是 VIP 以保证高可用

数据量大了之后就要分库分表了，于是就有了多主，就像 Redis 的分片集群一样，需要针对每个主配备多个从，如下

 
之前有读者问分库分表之后为啥还要做主从，现在我想大家应该都明白了，不是为了解决读写性能问题，主要是为了实现高可用

总结
看完了架构层面的高可用设计，相信大家对高可用的核心思想「冗余」和「自动故障转移」会有更深刻的体会，观察以上架构中的组件你会发现冗余的主要原因是因为只有一主，为什么不能有多主呢，也不是不可以，但这样在分布式系统下要保证数据的一致性是非常困难的，尤其是节点多了的话，数据之间的同步更是一大难题，所以多数组件采用一主的形式，然后再在主和多从之间同步，多数组件之所以选择一主本质上是技术上的 tradeoff

那么做好每个组件的高可用之后是否整个架构就真的可用了呢，非也，这只能说迈出了第一步，在生产上还有很多突发情况会让我们的系统面临挑战，比如

1. 瞬时流量问题：比如我们可能会面临秒杀带来的瞬时流量激增导致系统的承载能力被压垮，这种情况可能影响日常交易等核心链路，所以需要做到系统之间的隔离，如单独为秒杀部署一套独立的集群
2. 安全问题：比如 DDOS 攻击，爬虫频繁请求甚至删库跑路等导致系统拒绝服务
3. 代码问题：比如代码 bug 引起内存泄露导致 FullGC 导致系统无法响应等
4. 部署问题：在发布过程中如果贸然中止当前正在运行的服务也是不行的，需要做到优雅停机，平滑发布
5. 第三方问题：比如我们之前的服务依赖第三方系统，第三方可能出问题导致影响我们的核心业务
6. 不可抗力：如机房断电，所以需要做好容灾，异地多活，之前我司业务就由于机房故障导致服务四小时不可用，损失惨重
   所以除了做好架构的高可用之外，我们还需要在做好系统隔离，限流，熔断，风控，降级，对关键操作限制操作人权限等措施以保证系统的可用。

这里特别提一下降级，这是为了保证系统可用性采取的常用的措施，简单举几个例子

1. 我们之前对接过一个第三方资金方由于自身原因借款功能出了问题导致无法借款，这种情况为了避免引起用户恐慌，于是我们在用户申请第三方借款的时候返回了一个类似「为了提升你的额度，资金方正在系统升级」这样的文案，避免了客诉
2. 在流媒体领域，当用户观看直播出现严重卡顿时，很多企业的第一选择不是查 log 排查问题，而是为用户自动降码率。因为比起画质降低，卡得看不了显然会让用户更痛苦
3. 双十一零点高峰期，我们把用户的注册登录等非核心功能给停掉了，以保证下单等核心流程的顺利
   另外我们最好能做到事前防御，在系统出问题前把它扼杀在摇篮里，所以我们需要做单元测试，做全链路压测等来发现问题，还需要针对 CPU，线程数等做好监控，当其达到我们设定的域值时就触发告警以让我们及时发现修复问题（我司之前就碰到过一个类似的生产事故复盘大家可以看一下），此外在做好单元测试的前提下，依然有可能因为代码的潜在 bug 引起线上问题，所以我们需要在关键时间（比如双十一期间）封网（也就是不让发布代码）

此外我们还需要在出事后能快速定位问题，快速回滚，这就需要记录每一次的发布时间，发布人等，这里的发布不仅包括工程的发布，还包括配置中心等的发布

 
画外音：上图是我司的发布记录，可以看到有代码变更，回滚等，这样如果发现有问题的话可以一键回滚

最后我们以一张图来总结一下高可用的常见手段

 
··············  END  ··············

文章转自公众号：码海