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

大家好，我是坤哥

今天我们来聊一下互联网三高（高并发、高性能、高可用）中的高可用，看完本文相信能解开你关于高可用设计的大部分困惑

前言
高可用（High availability，即 HA）的主要目的是为了保障「业务的连续性」，即在用户眼里，业务永远是正常（或者说基本正常）对外提供服务的。高可用主要是针对架构而言，那么要做好高可用，就要首先设计好架构，第一步我们一般会采用分层的思想将一个庞大的 IT 系统拆分成为应用层，中间件，数据存储层等独立的层，每一层再拆分成为更细粒度的组件，第二步就是让每个组件对外提供服务，毕竟每个组件都不是孤立存在的，都需要互相协作，对外提供服务才有意义。

要保证架构的高可用，就要保证架构中所有组件以及其对外暴露服务都要做高可用设计，任何一个组件或其服务没做高可用，都意味着系统存在风险。

那么这么多组件该怎么做高可用设计呢，其实任何组件要做高可用，都离不开「冗余」和「自动故障转移」，众所周知单点是高可用的大敌，所以组件一般是以集群（至少两台机器）的形式存在的，这样只要某台机器出现问题，集群中的其他机器就可以随时顶替，这就是「冗余」。简单计算一下，假设一台机器的可用性为 90%，则两台机器组成的集群可用性为 1-0.1*0.1 = 99%，所以显然冗余的机器越多，可用性越高。

但光有冗余还不够，如果机器出现问题，需要人工切换的话也是费时费力，而且容易出错，所以我们还需要借助第三方工具（即仲裁者）的力量来实现「自动」的故障转移，以达到实现近实时的故障转移的目的，近实时的故障转移才是高可用的主要意义

怎样的系统可以称之为高可用呢，业界一般用几个九来衡量系统的可用性，如下

一般实现两个 9 很简单，毕竟每天宕机 14 分钟已经严重影响业务了，这样的公司迟早歇菜，大厂一般要求 4 个 9，其他要求严苛的业务要达到五个九以上，比如如果因为一个电脑的故障导致所有列车停驶，那么就会有数以万计的人正常生活受到阻碍，这种情况就要求五个九以上

接下来我们就来一起看看架构中的各个组件如何借助「冗余」和「自动故障转移」来实现高可用。

互联网架构剖析
目前多数互联网都会采用微服务架构，常见架构如下:

 
可以看到架构主要分以下几层

1. 接入层：主要由 F5 硬件或 LVS 软件来承载所有的流量入口
2. 反向代理层：Nginx，主要负责根据 url 来分发流量，限流等
3. 网关：主要负责流控，风控，协议转换等
4. 站点层：主要负责调用会员，促销等基本服务来装配 json 等数据并返回给客户端
5. 基础 service：其实与站点层都属于微服务，是平级关系，只不过基础 service 属于基础设施，能被上层的各个业务层 server 调用而已
6. 存储层：也就是 DB，如 MySQL，Oracle 等，一般由基础 service 调用返回给站点层
7. 中间件：ZK，ES，Redis，MQ 等，主要起到加速访问数据等功能，在下文中我们会简单介绍下各个组件的作用
   如前所述，要实现整体架构的高可用，必须要实现每一层组件的高可用，接下来我们就来分别看一下每一层的组件都是如何实现高可用的

接入层&反向代理层
这两层的高可用都和 keepalived 有关，所以我们结合起来一起看

 
对外，两个 LVS 以主备的形式对外提供服务，注意只有 master 在工作（即此时的 VIP 在 master 上生效），另外一个 backup 在 master 宕机之后会接管 master 的工作，那么 backup 怎么知道 master 是否正常呢，答案是通过 keepalived，在主备机器上都装上 keepalived 软件，启动后就会通过心跳检测彼此的健康状况，一旦  master 宕机，keepalived 会检测到，从而 backup 自动转成 master 对外提供服务，此时 VIP 地址（即图中的 115.204.94.139）即在 backup 上生效，也就是我们常说的「IP漂移」，通过这样的方式即解决了 LVS 的高可用。

keepalived 的心跳检测主要通过发送 ICMP 报文，或者利用 TCP 的端口连接和扫描检测来检测的，同样的，它也可以用来检测 Nginx 暴露的端口，这样的话如果某些 Nginx 不正常 Keepalived 也能检测到并将其从 LVS 能转发的服务列表中剔出。Nginx也能通过端口检测服务健康状态

借用 keepalived 这个第三方工具，同时实现了 LVS 和 Nginx 的高可用，同时在出现故障时也可以将宕机情况发送到对应开发人员的邮箱以让他们及时收到通知处理，确实很方便，Keepalived 应用广泛，下文我们会看到它也可以用在 MySQL 上来实现 MySQL 的高可用。

微服务
接下来我们再来看一下「网关」，「站点层」,「基础服务层」，这三者一般就是我们所说的微服务架构组件，当然这些微服务组件还需要通过一些 RPC 框架如 Dubbo 来支撑才能通信，所以微服务要实现高可用，就意味着 dubbo 这些 RPC 框架也要提供支撑微服务高可用的能力，我们就以 dubbo 为例来看下它是如何实现高可用的

我们先来简单地看下 dubbo 的基本架构

 
思路也很简单，首先是 Provider（服务提供者）向 Registry（注册中心，如 ZK 或 Nacos 等）注册服务，然后 Consumer（服务消费者）向注册中心订阅和拉取 Provider 服务列表，获取服务列表后，Consumer 就可以根据其负载均衡策略选择其中一个  Provider 来向其发出请求，当其中某个 Provider 不可用（下线或者因为 GC 阻塞等）时，会被注册中心及时监听（通过心跳机制）到，也会及时推送给 Consumer，这样 Consumer 就能将其从可用的 Provider 列表中剔除，也就实现了故障的自动转移，不难看出，注册中心就起到了类似 keepalived 的作用

中间件
我们再来看下这些中间件如 ZK，Redis 等是如何实现高可用的呢

ZK
上一节微服务中我们提到了注册中心，那我们就以 ZK（ZooKeeper）为例来看看它的高可用是如何实现的，先来看下它的整体架构图如下

 
Zookeeper 中的主要角色如下

• Leader: 即领导者，在集群中只有一个 Leader，主要承担了以下的功能
  1.事务请求的唯一调度和处理者，保证集群事务处理的顺序性，所有 Follower 的写请求都会转给 Leader 执行，用来保证事务的一致性
  2.集群内部各服务器的调度者：处理好事务请求后，会将数据广播同步到各个 Follower，统计 Follower 写入成功的数量，超过半数 Follower 写入成功，Leader 就会认为写请求提交成功，通知所有的 Follower commit 这个写操作，保证事后哪怕是集群崩溃恢复或者重启，这个写操作也不会丢失。
• Follower:
  1.处理客户端非事务请求、转发事务请求给 leader 服务器
  2.参与事物请求 Proposal 的投票（需要半数以上服务器通过才能通知 leader commit 数据; Leader 发起的提案，要求 Follower 投票）
  3.参与 Leader 选举的投票
  画外音：Zookeeper 3.0 之后新增了一种 Observer 的角色，不过与此处讨论的 ZK 高可用关系不是很大，为了简化问题，所以省略

可以看到由于只有一个 Leader，很显然，此 Leader 存在单点隐患，那么 ZK 是怎么解决此问题的呢，首先 Follower 与 Leader 会用心跳机制保持连接，如果 Leader 出现问题了（宕机或者因为 FullGC 等原因无法响应），Follower 就无法感知到 Leader 的心跳，就会认为 Leader 出问题了，于是它们就会发起投票选举，最终在多个 Follower 中选出一个 Leader 来（这里主要用到了 Zookeeper Atomic Broadcast，即 ZAB 协议，它是为 ZK 专门设计的一种支持崩溃恢复的一致性协议），选举的细节不是本文重点，就不在此详述了。

除了 ZAB 协议，业界上常用的还有 Paxos，Raft 等协议算法，也可以用在 Leader 选举上，也就是是在分布式架构中，这些协议算法承担了“第三者”也就是仲裁者的作用，以承担故障的自动转移

Redis
Redis 的高可用需要根据它的部署模式来看看，主要分为「主从模式」和「Cluster 分片模式」两种

主从模式
先来看一下主从模式，架构如下

 主从模式

主从模式即一主多从（一个或者多个从节点），其中主节点主要负责读和写，然后会将数据同步到多个从节点上，Client 也可以对多个从节点发起读请求，这样可以减轻主节点的压力，但和 ZK 一样，由于只有一个主节点，存在单点隐患，所以必须引入第三方仲裁者的机制来判定主节点是否宕机以及在判定主节点宕机后快速选出某个从节点来充当主节点的角色，这个第三方仲裁者在 Redis 中我们一般称其为「哨兵」（sentinel），当然哨兵进程本身也有可能挂掉，所以为了安全起见，需要部署多个哨兵（即哨兵集群）

 哨兵集群

这些哨兵通过 gossip（流言） 协议来接收关于主服务器是否下线的信息，并在判定主节点宕机后使用 Raft 协议来选举出新的主节点

文章转自公众号：码海