前言：Redis高可用包括两个层面，一个就是数据尽量减少丢失;另外一个就是保证Redis服务不中断。对于尽量减少数据丢失，可以通过AOF和RDB持久化机制保证；对于保证服务不中断的话，Redis就不能单点部署。所以为了提升Redis的并发能力和避免单点故障，可以搭建Redis集群架构：Redis主从、Redis哨兵或Redis Cluster集群。
一、Redis主从同步
主从同步复制功能是Redis高可用的基础，后面介绍的哨兵和Cluster集群都是在主从同步复制的基础上实现高可用的。
Redis 的同步方式有：主从同步、从从同步（由于全部都由 master 同步的话，会损耗性能，所以部分的 slave 会通过 slave 之间进行同步）。
1.1 Redsi主从概念
- Redis主从模式，就是部署多台Redis服务器，有主库和从库，它们之间通过主从复制，以保证数据副本的一致。
- 主从库之间采用的是读写分离的方式，其中主库负责写操作，从库则负责读操作。
- 如果Redis主库挂了，切换其中的从库成为主库。
1.2 Redis 主从同步过程
Redis主从同步包括三个阶段：
第一阶段：主从库间建立连接、协商同步。
- 从库向主库发送
psync命令，告诉它要进行数据同步。- 主库收到
psync命令后,响应FULLRESYNC命令（它表示第一次复制采用的是全量复制），并带上主库runID和主库目前的复制进度offset。
第二阶段：主库把数据同步到从库，从库收到数据后，完成本地加载。
- 主库执行
bgsave命令，生成RDB文件，接着将文件发给从库。从库接收到RDB文件后，会先清空当前数据库，然后加载 RDB 文件。- 主库把数据同步到从库的过程中，新来的写操作，会记录到
replication buffer。
第三阶段，主库把新写的命令，发送到从库。
主库完成RDB发送后，会把
replication buffer中的修改操作发给从库，从库再重新执行这些操作。这样主从库就实现同步了。
1.3 Redis主从的一些注意点
1.3.1 主从数据不一致
因为主从复制是异步进行的，如果从库滞后执行，则会导致主从数据不一致。
主从数据不一致一般有两个原因：
- 主从库网络延迟。
- 从库收到了主从命令，但是它正在执行阻塞性的命令（如
hgetall等）。
如何解决主从数据不一致问题呢？
- 可以换更好的硬件配置，保证网络畅通。
- 监控主从库间的复制进度
1.3.2 读取过期数据
Redis删除数据有这几种策略：
- 惰性删除：只有当访问一个key时，才会判断该key是否已过期，过期则清除。
- 定期删除：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。
- 主动删除：当前已用内存超过最大限定时，触发主动清理策略。
如果使用Redis版本低于3.2，读从库时，并不会判断数据是否过期，而是会返回过期数据。而3.2 版本后，Redis做了改进，如果读到的数据已经过期了，从库不会删除，却会返回空值，避免了客户端读到过期数据。
因此，在主从Redis模式下，尽量使用 Redis 3.2以上的版本。
1.3.3 一主多从，全量复制时主库压力问题
如果是一主多从模式，从库很多的时候，如果每个从库都要和主库进行全量复制的话，主库的压力是很大的。因为主库fork进程生成RDB，这个fork的过程是会阻塞主线程处理正常请求的。同时，传输大的RDB文件也会占用主库的网络宽带。
可以使用主-从-从模式解决。什么是主从从模式呢？其实就是部署主从集群时，选择硬件网络配置比较好的一个从库，让它跟部分从库再建立主从关系。如图：
1.3.4 主从网络断了怎么办呢？
主从库完成了全量复制后，它们之间会维护一个网络长连接，用于主库后续收到写命令传输到从库，它可以避免频繁建立连接的开销。但是，如果网络断开重连后，是否还需要进行一次全量复制呢？
如果是Redis 2.8之前，从库和主库重连后，确实会再进行一次全量复制，但是这样开销就很大。而Redis 2.8之后做了优化，重连后采用增量复制方式，即把主从库网络断连期间主库收到的写命令，同步给从库。
主从库重连后，就是利用repl_backlog_buffer实现增量复制。
当主从库断开连接后，主库会把断连期间收到的写操作命令，写入replication buffer，同时也会把这些操作命令写入repl_backlog_buffer这个缓冲区。repl_backlog_buffer是一个环形缓冲区，主库会记录自己写到的位置，从库则会记录自己已经读到的位置。
二、Redis Sentinel 哨兵集群
在 Redis 主从复制模式下，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址，对于很多应用方是无法接受的。于是 Redis 从2.8开始正式提供了 Redis Sentinel 哨兵机制来解决这个问题，做到真正的不用人工参与的高可用故障转移。
Redis 的主从切换是通过哨兵来解决的。这里哨兵主要解决的问题就是：当 master 挂了的情况下，如果在短时间内重新选举出一个新的 master 。
Sentinel 集群是一个由 3-5 个（可以更多）节点组成的，用来监听整个 Redis 的集群，如果发现 master 不可用的时候，会关闭和断开全部的与 master 相连的旧链接。这个时候 Sentinel 会完成选举和故障转移，新的请求则会转到新到 master 中。
2.1 哨兵作用
哨兵其实是一个运行在特殊模式下的Redis进程。它有三个作用，分别是：监控、自动选主切换（简称选主）、通知。
哨兵进程在运行期间，监视所有的Redis主节点和从节点。它通过周期性给主从库发送PING命令，检测主从库是否挂了。如果从库没有在规定时间内响应哨兵的PING命令，哨兵就会把它标记为下线状态；如果主库没有在规定时间内响应哨兵的PING命令，哨兵则会判定主库下线，然后开始切换到选主任务。
所谓选主，其实就是从多个从库中，按照一定规则，选出一个当做主库。至于通知呢，就是选出主库后，哨兵把新主库的连接信息发给其他从库，让它们和新主库建立主从关系。同时，哨兵也会把新主库的连接信息通知给客户端，让它们把请求操作发到新主库上。
2.2 哨兵如何判定主库下线
哨兵是如何判断主库是否下线的呢？我们先来了解两个基础概念哈：主观下线和客观下线。
- 哨兵进程向主库、从库发送PING命令，如果主库或者从库没有在规定的时间内响应PING命令，哨兵就把它标记为主观下线。
- 如果是主库被标记为主观下线，则正在监视这个主库的所有哨兵要以每秒一次的频率，以确认主库是否真的进入了主观下线。当有多数的哨兵（一般少数服从多数，由 Redis 管理员自行设定的一个值）在指定的时间范围内确认主库的确进入了主观下线状态，则主库会被标记为客观下线。这样做的目的就是避免对主库的误判，以减少没有必要的主从切换，减少不必要的开销。
假设我们有
N个哨兵实例，如果有N/2+1个实例判断主库主观下线，此时就可以把节点标记为客观下线，就可以做主从切换了。
2.3 哨兵是如何选主的？
如果明确主库已经客观下线了，哨兵就开始了选主模式。
哨兵选主包括两大过程，分别是：过滤和打分。其实就是在多个从库中，先按照一定的筛选条件，把不符合条件的从库过滤掉。然后再按照一定的规则，给剩下的从库逐个打分，将得分最高的从库选为新主库
- 选主时，会判断从库的状态，如果已经下线，就直接过滤。
- 如果从库网络不好，老是超时，也会被过滤掉。看这个参数
down-after-milliseconds，它表示我们认定主从库断连的最大连接超时时间。 - 过滤掉了不适合做主库的从库后，就可以给剩下的从库打分，按这三个规则打分：从库优先级、从库复制进度以及从库ID号。
- 从库优先级最高的话，打分就越高，优先级可以通过
slave-priority配置。如果优先级一样，就选与旧的主库复制进度最快的从库。如果优先级和从库进度都一样，从库ID 号小的打分高。
2.4 由哪个哨兵执行主从切换呢？
一个哨兵标记主库为主观下线后，它会征求其他哨兵的意见，确认主库是否的确进入了主观下线状态。它向其他实例哨兵发送is-master-down-by-addr命令。其他哨兵会根据自己和主库的连接情况，回应Y或N（Y 表示赞成，N表示反对票）。如果这个哨兵获取得足够多的赞成票数（quorum配置），主库会被标记为客观下线。
标记主库客观下线的这个哨兵，紧接着向其他哨兵发送命令，再发起投票，希望它可以来执行主从切换。这个投票过程称为Leader 选举。因为最终执行主从切换的哨兵称为Leader，投票过程就是确定Leader。一个哨兵想成为Leader需要满足两个条件：
- 需要拿到
num(sentinels)/2+1的赞成票。 - 并且拿到的票数需要大于等于哨兵配置文件中的
quorum值。
举个例子，假设有3个哨兵。配置的quorum值为2。即一个一个哨兵想成为Leader至少需要拿到2张票。
2.5 故障转移
假设哨兵模式架构如下，有三个哨兵，一个主库M，两个从库S1和S2。
当哨兵检测到Redis主库M1出现故障，那么哨兵需要对集群进行故障转移。假设选出了哨兵3作为Leader。故障转移流程如下：
- 从库S1解除从节点身份，升级为新主库
- 从库S2成为新主库的从库
- 原主节点恢复也变成新主库的从节点
- 通知客户端应用程序新主节点的地址。
故障转移后：
三、Redis Cluster 切片集群
Redis Sentinel 完美的解决了自动故障转移问题，但是当遇到单机内存、并发、流量等瓶颈时，我们就需要考虑采用 Redis Cluster 架构方案达到Redis数据分布式存储和负载均衡的目的。
3.1 有了Redis哨兵机制，为什么还出现Redis Cluster？
Redis 哨兵模式基于主从模式，实现读写分离，它还可以自动切换，系统可用性更高。但是它每个节点存储的数据是一样的，浪费内存，并且不好在线扩容。因此，Redis Cluster 应运而生，它是从Redis3.0版本开始，官方提供的一种实现切片集群的方案，实现了Redis的分布式存储。
Redis Cluster 对数据进行分片，也就是说每台Redis节点上存储不同的内容，来解决在线扩容的问题。并且，它可以保存大量数据，即分散数据到各个Redis实例，还提供复制和故障转移的功能。
比如你一个Redis实例保存15G甚至更大的数据，响应就会很慢，这是因为Redis RDB 持久化机制导致的，Redis会fork子进程完成 RDB 持久化操作，fork执行的耗时与 Redis 数据量成正相关。
这时候你很容易想到，把15G数据分散来存储就好了嘛。这就是Redis切片集群的初衷。切片集群是啥呢？来看个例子，如果你要用Redis保存15G的数据，可以用单实例Redis，或者3台Redis实例组成切片集群，对比如下：
既然数据是分片分布到不同Redis实例的，那客户端到底是怎么确定想要访问的数据在哪个实例上呢？我们一起来看下Reids Cluster是怎么做的哈。
3.2 Redis Cluster集群工作原理
Redis 集群通过哈希槽指派机制来决定写命令应该被分配到那个节点。整个集群对应的槽是由 16384 大小的二进制数组组成，集群中每个主节点分配一部分槽，每条写命令落到二进制数组中的某个位置，该位置被分配给了哪个节点，则对应的命令就由该节点去执行。槽指派对应的二进制数组如下图所示：
从上图可以看到：节点 1 只负责 执行 0 - 4999 的槽位，而节点 2 负责执行 5000 - 9999，节点 3 执行 9999- 16383 。当进行写的时候：
set key value命令通过 CRC16(key) & 16383 = 6789（假设结果），由于节点 2 负责 5000～9999 的槽位，则该命令的结果 6789 最终由节点 2 执行。当然如果在节点 2 执行一条命令时，假设通过 CRC 计算后得到的值为 567，则其应该由节点 1 执行，此时命令会进行转向操作，将要执行的命令流转到节点 1 上去执行。
3.3 哈希槽（Hash Slot）
Redis Cluster方案采用哈希槽（Hash Slot），来处理数据和实例之间的映射关系。
一个切片集群被分为16384个slot（槽），每个进入Redis的键值对，根据key进行散列，分配到这16384插槽中的一个。使用的哈希映射也比较简单，用CRC16算法计算出一个16bit的值，再对16384取模。数据库中的每个键都属于这16384个槽的其中一个，集群中的每个节点都可以处理这16384个槽。
集群中的每个节点负责一部分的哈希槽，假设当前集群有A、B、C3个节点，每个节点上负责的哈希槽数 =16384/3，那么可能存在的一种分配：
- 节点A负责0~5460号哈希槽
- 节点B负责5461~10922号哈希槽
- 节点C负责10923~16383号哈希槽
客户端给一个Redis实例发送数据读写操作时，如果这个实例上并没有相应的数据，会怎么样呢？MOVED重定向和ASK重定向了解一下哈
3.4 MOVED重定向和ASK重定向
在Redis cluster模式下，节点对请求的处理过程如下：
- 通过哈希槽映射，检查当前Redis key是否存在当前节点
- 若哈希槽不是由自身节点负责，就返回MOVED重定向
- 若哈希槽确实由自身负责，且key在slot中，则返回该key对应结果
- 若Redis key不存在此哈希槽中，检查该哈希槽是否正在迁出（MIGRATING）？
- 若Redis key正在迁出，返回ASK错误重定向客户端到迁移的目的服务器上
- 若哈希槽未迁出，检查哈希槽是否导入中？
- 若哈希槽导入中且有ASKING标记，则直接操作，否则返回MOVED重定向
3.4.1 Moved 重定向
客户端给一个Redis实例发送数据读写操作时，如果计算出来的槽不是在该节点上，这时候它会返回MOVED重定向错误，MOVED重定向错误中，会将哈希槽所在的新实例的IP和port端口带回去。这就是Redis Cluster的MOVED重定向机制。流程图如下：
3.4.2 ASK 重定向
Ask重定向一般发生于集群伸缩的时候。集群伸缩会导致槽迁移，当我们去源节点访问时，此时数据已经可能已经迁移到了目标节点，使用Ask重定向可以解决此种情况。
3.5 Cluster集群节点的通讯协议：Gossip
一个Redis集群由多个节点组成，各个节点之间是怎么通信的呢？通过Gossip协议！Gossip是一种谣言传播协议，每个节点周期性地从节点列表中选择 k 个节点，将本节点存储的信息传播出去，直到所有节点信息一致，即算法收敛了。
Gossip协议基本思想：一个节点想要分享一些信息给网络中的其他的一些节点。于是，它周期性的随机选择一些节点，并把信息传递给这些节点。这些收到信息的节点接下来会做同样的事情，即把这些信息传递给其他一些随机选择的节点。一般而言，信息会周期性的传递给N个目标节点，而不只是一个。这个N被称为fanout。
Redis Cluster集群通过Gossip协议进行通信，节点之前不断交换信息，交换的信息内容包括节点出现故障、新节点加入、主从节点变更信息、slot信息等等。gossip协议包含多种消息类型，包括ping，pong，meet，fail，等等
- meet消息：通知新节点加入。消息发送者通知接收者加入到当前集群，meet消息通信正常完成后，接收节点会加入到集群中并进行周期性的ping、pong消息交换。
- ping消息：节点每秒会向集群中其他节点发送 ping 消息，消息中带有自己已知的两个节点的地址、槽、状态信息、最后一次通信时间等
- pong消息：当接收到ping、meet消息时，作为响应消息回复给发送方确认消息正常通信。消息中同样带有自己已知的两个节点信息。
- fail消息：当节点判定集群内另一个节点下线时，会向集群内广播一个fail消息，其他节点接收到fail消息之后把对应节点更新为下线状态。
特别的，每个节点是通过集群总线(cluster bus) 与其他的节点进行通信的。通讯时，使用特殊的端口号，即对外服务端口号加10000。例如如果某个node的端口号是6379，那么它与其它nodes通信的端口号是 16379。nodes 之间的通信采用特殊的二进制协议。
3.6 为什么Redis Cluster的Hash Slot 是16384？
对于客户端请求过来的键值key，哈希槽= CRC16(key) % 16384，CRC16算法产生的哈希值是16bit的，按道理该算法是可以产生2^16=65536个值，为什么不用65536，用的是16384（2^14）呢？
大家可以看下作者的原始回答：
Redis 每个实例节点上都保存对应有哪些slots，它是一个unsigned char slots[REDIS_CLUSTER_SLOTS/8] 类型
- 在redis节点发送心跳包时需要把所有的槽放到这个心跳包里，如果slots数量是
65536，占空间=65536 / 8(一个字节8bit) / 1024(1024个字节1kB) =8kB，如果使用slots数量是16384，所占空间 =16384 / 8(每个字节8bit) / 1024(1024个字节1kB) = 2kB，可见16384个slots比 65536省 6kB内存左右，假如一个集群有100个节点,那每个实例里就省了600kB啦 - 一般情况下Redis cluster集群主节点数量基本不可能超过1000个，超过1000会导致网络拥堵。对于节点数在1000以内的Redis cluster集群，16384个槽位其实够用了。
既然为了节省内存网络开销，为什么 slots不选择用8192（即16384/2） 呢?
假如 slots 设置成 8192, 200个实例的节点情况下,理论值是 每40个不同key请求,命中就会失效一次,假如节点数增加到400,那就是20个请求。并且1kb 并不会比 2k 省太多,性价比不是特别高,所以可能 选16384会更为通用一点
参考链接：
