高可用性（HA），原本是系统的一个特性，旨在确保在高于平均水平的时间内保持约定的运行性能水平，通常是正常运行时间。

Redis 作为一个内存数据库，其数据通常存储在内存中，一旦发生故障，可能导致数据丢失或服务中断，避免单点故障至关重要，这样系统才能顺利快速地恢复。

Redis 高可用是指 Redis 通过一系列技术手段确保在面临故障的情况下也能持续提供服务的能力。

由于我们现在已经进入了一个分布式系统，并且需要考虑许多错误，因此在这个拓扑结构中需要考虑一些新问题，以前简单的事情现在变得更加复杂。

为了保证 Redis 的高可用，它主要采用了以下三种手段：

接下来，我们逐个来分析看看。

1、Redis 主从复制

主从复制是 Redis 多机运行中最基础的功能，它是把多个 Redis 节点组成一个 Redis 集群，在这个集群当中有一个主节点用来进行数据的操作，其他从节点用于同步主节点的内容，并且提供给客户端进行数据查询。

Redis 主从同步分为：

1.1 全量复制

全量复制主要的实施流程，包括以下几个方面：

当我们启动多个 Redis 实例的时候，它们相互之间就可以通过 replicaof（Redis 5.0 之前使用 slaveof）命令形成主库和从库的关系

/* * 主：实例 1（ip：172.168.0.1） * 从：实例 2（ip：172.168.0.2） * 在从库上执行以下命令 */replicaof  

1）主从库间建立连接、协商同步

从库给主库发送 psync 命令，表示要进行数据同步，主库根据这个命令的参数来启动复制。

psync 命令包含了主库的 runID 和复制进度 offset 两个参数：

2）主库将所有数据同步给从库

主库执行 bgsave 命令，生成 RDB 文件，接着将文件发给从库。从库接收到 RDB 文件后，会先清空当前数据库，然后加载 RDB 文件。

在主库将数据同步给从库的过程中，主库不会被阻塞，仍然可以正常接收请求，否则，Redis 的服务就被中断了。但是，这些请求中的写操作并没有记录到刚刚生成的 RDB 文件中。为了保证主从库的数据一致性，主库会在内存中用专门的 replication buffer，记录 RDB 文件生成后收到的所有写操作。

3）主库会把第二阶段执行过程中新收到的写命令，再发送给从库

当主库完成 RDB 文件发送后，就会把此时 replication buffer 中的修改操作发给从库，从库再重新执行这些操作。

1.2 增量复制

此功能在 Redis 2.8 版本才引入，主要为了控制主从复制的成本开销。网络断了之后，主从库会采用增量复制的方式继续同步。

先来看一个概念：replication_backlog复制积压缓冲区。

此命令一方面会传输给从节点，另外还会记录在这个复制积压缓冲区里。Redis 使用一个环形缓冲区的结构保存最近的一些命令。在缓冲区中，对字节进行编号，这个编号在 Redis 中叫复制偏移量。

是否满足增量同步的条件：

2、Redis 哨兵模式

哨兵模式是redis高可用的实现方式之一，使用一个或者多个哨兵(Sentinel)实例组成的系统，对redis节点进行监控，在主节点出现故障的情况下，能将从节点中的一个升级为主节点，进行故障转义，保证系统的可用性。

2.1 哨兵实现了什么功能呢？

以这种方式使用 Redis Sentinel 可以进行故障检测。此检测涉及多个哨兵进程同意当前主实例不再可用。这个协议过程称为 Quorum。这可以提高鲁棒性并防止一台机器行为异常导致无法访问主 Redis 节点。

2.2 自动故障转移

哨兵（Sentinel）节点会每秒一次的频率向建立了命令连接的实例发送 PING 命令，如果在down-after-milliseconds 毫秒内没有做出有效响应，包括（PONG/LOADING/MASTERDOWN）以外的响应，哨兵就会将该实例在本结构体中的状态标记为 SRI_S_DOWN 主观下线。

当一个哨兵节点发现主节点处于主观下线状态时，会向其他的哨兵节点发出询问，该节点是不是已经主观下线了。

如果超过配置参数 quorum 个节点认为是主观下线时，该哨兵节点就会将自己维护的结构体中该主节点标记为 SRI_O_DOWN 客观下线 询问命令：

SENTINEL masterdownaddr current_epoch run_id

在认为主节点客观下线的情况下，哨兵节点节点间会发起一次选举，命令如下：

SENTINEL masterdownaddr current_epoch run_id

只是这次会将自己的 run_id 带进去，希望接受者将自己设置为主节点。

如果超过半数以上的节点返回将该节点标记为 leader 的情况下，会由该 leader 对故障进行转移。

在从节点中挑选出新的主节点

a. 通讯正常

b. 优先级排序

c. 优先级相同是选择offset最大的

将该节点设置成新的主节点 SLAVEOF no one,并确保在后续的INGO命令时，该节点返回状态为master

将其他的从节点设置成从新的主节点复制, SLAVEOF命令

将旧的主节点变成新的主节点的从节点

3、Redis 集群Cluster

Cluster 即 集群模式。类似MySQL，Redis 集群也是一种分布式数据库方案，集群通过分片（sharding）模式来对数据进行管理，并具备分片间数据复制、故障转移和流量调度的能力。

Redis Cluster 允许 Redis 的水平扩展。

3.1 集群Cluster 介绍

Redis 集群将数据划分为 16384（2的14次方）个哈希槽（slots），如果你有多个实例节点，那么每个实例节点将管理其中一部分的槽位，槽位的信息会存储在各自所归属的节点中。以下图为例，该集群有4个 Redis 节点，每个节点负责集群中的一部分数据，数据量可以不均匀。比如性能好的实例节点可以多分担一些压力。

一个Redis集群一共有16384个哈希槽，你可以有1 ~ n个节点来分配这些哈希槽，可以不均匀分配，每个节点可以处理0个 到至多 16384 个槽点。当16384个哈希槽都有节点进行管理的时候，集群处于online 状态。同样的，如果有一个哈希槽没有被管理到，那么集群处于offline状态。

上面图中4个实例节点组成了一个集群，集群之间的信息通过Gossip协议进行交互，这样就可以在某一节点记录其他节点的哈希槽（slots）的分配情况。

3.2 Cluster模式扩展

单机的吞吐无法承受持续扩增的流量的时候，最好的办法是从横向（scale out） 和 纵向（scale up）两方面进行扩展：

4、总结

高可用一般来说有两个含义：1）数据尽量不丢失，2）保证服务尽可能可用。

AOF 和 RDB 数据持久化保证了数据尽量不丢失，而多节点来保证服务尽可能提供服务。单个节点的系统吞吐量有限，容量也有限，缺点明显，一旦发生故障会导致服务不可用。