Redis高可用的三种实现方式
一、 高可用的概念
高可用(High Availability,即HA)，指的是通过尽量缩短日常维护操作和突发的系统崩溃所导致的停机时间，以提高系统和应用的可用性。一个业务系统如果全年无一时刻不在提供服务，它的可用性可达100%。那么什么样的系统可以称之为高可用呢，业界一般用几个九来衡量系统的可用性，当系统运行时间达到4个九即99.99%时的系统为高可用的，全年宕机时间为52分钟左右。
高可用一般来说有两个含义：一是数据尽量不丢失，二是保证服务尽可能可用。 AOF 和 RDB 数据持久化保证了数据尽量不丢失,而多节点来保证服务尽可能提供服务。单个节点的系统缺点明显，一旦发生故障会导致服务不可用。而且，单个节点处理所有的请求，吞吐量有限，容量也有限。
二、 高可用的实现方式
Redis实现高可用，在于提供多个节点，通常有三种部署模式：主从模式，哨兵模式，集群模式。
1.主从模式
主从模式就是，部署多台Redis节点，其中只有一台节点是主节点（master），其他的节点都是从节点（slave）。主从模式实现读写分离，只有master节点提供数据的事务性操作（增删改），slave节点只提供读操作。所有slave节点的数据都是从master节点同步过来的，该模式的结构图如下：
①主从库间如何进行第一次同步？
当我们启动多个 Redis 实例的时候，它们相互之间就可以通过 replicaof（Redis 5.0 之前使用 slaveof）命令形成主库和从库的关系，之后会按照三个阶段完成数据的第一次同步。例如，现在有实例 1（ip：172.16.19.3）和实例 2（ip：172.16.19.5），我们在实例 2 上执行以下这个命令后，实例 2 就变成了实例 1 的从库，并从实例 1 上复制数据：
replicaof 172.16.19.3 6379
主从库间数据第一次同步的三个阶段,如下图所示:
② 主从级联模式分担全量复制时的主库压力
一次全量复制中，对于主库来说，需要完成两个耗时的操作：生成 RDB 文件和传输 RDB 文件。如果从库数量很多，而且都要和主库进行全量复制的话，就会导致主库忙于 fork 子进程生成 RDB 文件，进行数据全量同步。fork 这个操作会阻塞主线程处理正常请求，从而导致主库响应应用程序的请求速度变慢。此外，传输 RDB 文件也会占用主库的网络带宽，同样会给主库的资源使用带来压力。我们可以通过“主 - 从 - 从”模式将主库生成 RDB 和传输 RDB 的压力，以级联的方式分散到从库上,如下图所示。
简单来说，我们在部署主从集群的时候，可以手动选择一个从库（比如选择内存资源配置较高的从库），用于级联其他的从库。然后，我们可以再选择一些从库（例如三分之一的从库），在这些从库上执行如下命令，让它们和刚才所选的从库，建立起主从关系。
replicaof 所选从库IP 6379
③ 主从复制策略
一旦主从库完成了全量复制，它们之间就会一直维护一个网络长连接。从 Redis 2.8 开始，网络断了之后，主从库会采用增量复制的方式继续同步。当主从库断连后，主库会把断连期间收到的写操作命令，写入 replication buffer，同时也会把这些操作命令也写入 repl_backlog_buffer 这个缓冲区。repl_backlog_buffer 是一个环形缓冲区，主库会记录自己写到的位置，从库则会记录自己已经读到的位置。增量复制过程如下图所示:
不过，因为 repl_backlog_buffer 是一个环形缓冲区，所以在缓冲区写满后，主库会继续写入，此时，就会覆盖掉之前写入的操作。如果从库的读取速度比较慢，就有可能导致从库还未读取的操作被主库新写的操作覆盖了，这会导致主从库间的数据不一致。我们可以调整 repl_backlog_size 这个参数,repl_backlog_size = 缓冲空间大小 * 2，缓冲空间大小 = 主库写入命令速度 * 操作大小 - 主从库间网络传输命令速度 * 操作大小。不过，如果并发请求量非常大，连两倍的缓冲空间都存不下新操作请求的话，此时，主从库数据仍然可能不一致。针对这种情况，一方面，你可以根据 Redis 所在服务器的内存资源再适当增加repl_backlog_size 值，比如说设置成缓冲空间大小的 4 倍，另一方面，可以考虑使用切片集群来分担单个主库的请求压力。
2.哨兵模式
在主从模式中，一旦master节点发生宕机，为了保证高可用，需要找一个slave节点作为新的master节点。谁来确定宕机，选择哪一个slave节点，这些问题都没有解决。哨兵(sentinal)模式则是为了解决这些问题而产生的，它用于对主从模式中每个节点进行监控，当出现故障时通过投票机制，选择新的master节点，并将所有的slave节点连接到master节点。
哨兵主要负责的就是三个任务：监控、选主（选择主库）和通知。
①监控
哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况，用来判断实例的状态。如果哨兵发现主库或从库对 PING 命令的响应超时了，那么，哨兵就会先把它标记为“主观下线”。如果检测的是从库，那么，哨兵简单地把它标记为“主观下线”就行了。如果检测的是主库，需要引入哨兵集群来减少误判。
简单来说，“客观下线”的标准就是，当有 N 个哨兵实例时，最好要有 N/2 + 1 个实例判断主库为“主观下线”，才能最终判定主库为“客观下线”。这样一来，就可以减少误判的概率，也能避免误判带来的无谓的主从库切换。（当然，有多少个实例做出“主观下
线”的判断才可以，可以由 Redis 管理员自行设定）。
②选主
哨兵选择新主库的过程称为“筛选 + 打分”。
除了要检查从库的当前在线状态，还要判断它之前的网络连接状态。
可以分别按照三个规则依次进行三轮打分，这三个规则分别是从库优先级、从库复制进度以及从库 ID 号。
基于pub/sub 机制，哨兵和哨兵之间、哨兵和从库之间、哨兵和客户端之间就都能建立起连接了，哨兵集群的监控、选主和通知三个任务就基本可以正常工作了。不过，我们还需要考虑一个问题：主库故障以后，哨兵集群有多个实例，那怎么确定由哪个哨兵来进行实际的主从切换呢？
任何一个实例只要自身判断主库“主观下线”后，就会给其他实例发送 is-master-down-by-addr 命令。接着，其他实例会根据自己和主库的连接情况，做出 Y 或 N 的响应，Y 相当于赞成票，N 相当于反对票。
一个哨兵获得了仲裁所需的赞成票数后，就可以标记主库为“客观下线”。这个所需的赞成票数是通过哨兵配置文件中的 quorum 配置项设定的。
此时，这个哨兵就可以再给其他哨兵发送命令，表明希望由自己来执行主从切换，并让所有其他哨兵进行投票。在投票过程中，任何一个想成为 Leader 的哨兵，要满足两个条件：第一，拿到半数以上的赞成票；第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。
需要注意的是，如果哨兵集群只有 2 个实例，此时，一个哨兵要想成为 Leader，必须获得2 票，而不是 1 票。所以，如果有个哨兵挂掉了，那么，此时的集群是无法进行主从库切换的。因此，通常我们至少会配置 3 个哨兵实例。这一点很重要，你在实际应用时可不能忽略了。
3. 集群模式
为了保存大量数据，我们使用了大内存云主机和切片集群两种方法。实际上，这两种方法分别对应着 Redis 应对数据量增多的两种方案：纵向扩展（scale up）和横向扩展（scale out）。纵向扩展会受到硬件和成本的限制。
从 Redis3.0 开始，官方提供了一个名为 Redis Cluster 的方案，用于实现切片集群。Redis Cluster 方案中就规定了数据和实例的对应规则。在 Redis Cluster 方案中，一个切片集群共有 16384个哈希槽，首先根据键值对的 key，按照 CRC16 算法计算一个 16 bit的值；然后，再用这个 16bit 值对 16384 取模，得到 0~16383 范围内的模数，每个模数代表一个相应编号的哈希槽。
我们在部署 Redis Cluster 方案时，可以使用 cluster create 命令创建集群，此时，Redis会自动把这些槽平均分布在集群实例上。例如，如果集群中有 N 个实例，那么，每个实例上的槽个数为 16384/N 个。当然， 我们也可以使用 cluster meet 命令手动建立实例间的连接，形成集群，再使用cluster addslots 命令，指定每个实例上的哈希槽个数。在手动分配哈希槽时，需要把 16384 个槽都分配完，否则Redis 集群无法正常工作。
redis-cli -h 172.16.19.3 –p 6379 cluster addslots 0,1 redis-cli -h 172.16.19.4 –p 6379 cluster addslots 2,3 redis-cli -h 172.16.19.5 –p 6379 cluster addslots 4
在集群运行的过程中，key1 和 key2 计算完 CRC16 值后，对哈希槽总个数 5 取模，再根据各自的模数结果，就可以被映射到对应的实例 1 和实例 3 上了。
Redis 实例会把自己的哈希槽信息发给和它相连接的其它实例，来完成哈希槽分配信息的扩散。当实例之间相互连接后，每个实例就有所有哈希槽的映射关系了。客户端和集群实例建立连接后，实例就会把哈希槽的分配信息发给客户端。客户端收到哈希槽信息后，会把哈希槽信息缓存在本地。当客户端请求键值对时，会先计算键所对应的哈希槽，然后就可以给相应的实例发送请求了。实例和哈希槽的对应关系并不是一成不变的，Redis Cluster 方案提供了一种重定向机制，所谓的“重定向”，就是指，客户端给一个实例发送数据读写操作时，这个实例上并没有相应的数据，客户端要再给一个新实例发送操作命令。当客户端把一个键值对的操作请求发给一个实例时，如果这个实例上并没有这个键值对映射的哈希槽，那么，这个实例就会给客户端返回下面的 MOVED 命令响应结果，这个结果中就包含了新实例的访问地址。
GET hello:key (error) MOVED 13320 172.16.19.5:6379
在上图中，当客户端给实例 2 发送命令时，Slot 2 中的数据已经全部迁移到了实例 3。在实际应用时，如果 Slot 2 中的数据比较多，就可能会出现一种情况：客户端向实例 2 发送请求，但此时，Slot 2 中的数据只有一部分迁移到了实例 3，还有部分数据没有迁移。在这种迁移部分完成的情况下，客户端就会收到一条 ASK 报错信息，如下所示：
GET hello:key (error) ASK 13320 172.16.19.5:6379
和 MOVED 命令不同，ASK 命令并不会更新客户端缓存的哈希槽分配信息。所以，在上图中，如果客户端再次请求 Slot 2 中的数据，它还是会给实例 2 发送请求。这也就是说，ASK 命令的作用只是让客户端能给新实例发送一次请求，而不像 MOVED 命令那样，会更改本地缓存，让后续所有命令都发往新实例。