目录

1、主从复制(Replication)

1.1 主从数据库

1.2 主从复制的特点

1.3 主从复制的优缺点

2、哨兵(Sentinel)

2.1 Redis哨兵主要功能

2.2 Redis哨兵高可用原理

2.3 Redis哨兵故障切换的过程

2.4 Redis哨兵模式的工作方式

2.5 Redis哨兵模式的优缺点

3、集群(Cluster)

3.1 Redis-Cluster集群的配置

3.2 Redis-Cluster集群的特点

3.3 Redis-Cluster集群的工作方式

3.4 Redis-Cluster集群的优缺点

Redis Cluster是Redis的分布式集群解决方案，在 3.0 版本正式推出。在3.0之前的集群方案主要是主从复制和哨兵机制，3种方案各有优缺点。

• 主从复制(Replication)主要是备份数据、读写分离、负载均衡，一个Master可以有多个Slaves服务器作为备份。
• 哨兵(Sentinel)是为了高可用，可以管理多个Redis服务器，提供了监控，提醒以及自动的故障转移的功能。sentinel发现master挂了后，就会从slave(从服务器)中重新选举一个master(主服务器)。
• 集群(cluster)则是为了解决单机Redis容量有限/能力有限的问题，将数据按一定的规则分配到多台机器，提高并发量，内存/QPS不受限于单机，可受益于分布式集群高扩展性。

1、主从复制(Replication)

同Mysql主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了解决单点数据库问题，分担读压力，Redis支持主从复制(把数据复制多个副本部署到其他节点上)，读写分离，实现Redis的高可用性，冗余备份保证数据和服务的高度可靠性。一个Master可以有多个Slaves。

• ①从数据库向主数据库发送sync(数据同步)命令。
• ②主数据库接收同步命令后，会保存快照，创建一个RDB文件。
• ③当主数据库执行完保持快照后，会向从数据库发送RDB文件，而从数据库会接收并载入该文件。
• ④主数据库将缓冲区的所有写命令发给从服务器执行。
• ⑤以上处理完之后，之后主数据库每执行一个写命令，都会将被执行的写命令发送给从数据库。
• 注意：在Redis2.8之后，主从断开重连后会根据断开之前最新的命令偏移量进行增量复制

1.1 主从数据库

在复制的概念中，数据库分为两类，一类是主数据库（master），另一类是从数据库(slave）。主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。

1.2 主从复制的特点

• 主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库
• 从数据库一般都是只读的，并且接收主数据库同步过来的数据
• 一个master可以拥有多个slave，但是一个slave只能对应一个master
• slave挂了不影响其他slave的读和master的读和写，重新启动后会将数据从master同步过来
• master挂了以后，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务
• master挂了以后，不会在slave节点中重新选一个master

1.3 主从复制的优缺点

优点：

1. 支持主从复制，主机会自动将数据同步到从机，数据备份的同时可以进行读写分离，提高服务器性能；
2. 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成；
3. Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力；
4. Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求；
5. Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据；

缺点：

1. Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复；
2. 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性；
3. 如果多个Slave断线了，需要重启的时候，尽量不要在同一时间段进行重启。因为只要Slave启动，就会发送sync请求和主机全量同步，当多个 Slave 重启的时候，可能会导致 Master IO剧增从而宕机。
4. Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂；

2、哨兵(Sentinel)

主从同步/复制的模式，当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。哨兵是Redis集群架构中非常重要的一个组件，哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

Redis Sentinel是社区版本推出的原生高可用解决方案，其部署架构主要包括两部分：Redis Sentinel集群和Redis数据集群。

其中Redis Sentinel集群是由若干Sentinel节点组成的分布式集群，可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel的节点数量要满足2n+1（n>=1）的奇数个。

2.1 Redis哨兵主要功能

• 集群监控：负责监控Redis master和slave进程是否正常工作
• 消息通知：如果某个Redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
• 故障转移：如果master node挂掉了，会自动转移到slave node上
• 配置中心：如果故障转移发生了，通知client客户端新的master地址

2.2 Redis哨兵高可用原理

当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

• 哨兵机制建立了多个哨兵节点(进程)，共同监控数据节点的运行状况。
• 同时哨兵节点之间也互相通信，交换对主从节点的监控状况。
• 每隔1秒每个哨兵会向整个集群：Master主服务器+Slave从服务器+其他Sentinel（哨兵）进程，发送一次ping命令做一次心跳检测。

这个就是哨兵用来判断节点是否正常的重要依据，涉及两个概念：主观下线和客观下线。

• 主观下线：一个哨兵节点判定主节点down掉是主观下线。
• 客观下线：只有半数哨兵节点都主观判定主节点down掉，此时多个哨兵节点交换主观判定结果，才会判定主节点客观下线。

基本上哪个哨兵节点最先判断出这个主节点客观下线，就会在各个哨兵节点中发起投票机制Raft算法（选举算法），最终被投为领导者的哨兵节点完成主从自动化切换的过程。

2.3 Redis哨兵故障切换的过程

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行 failover 过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象称为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行 failover 操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。对于客户端而言，一切都是透明的。

2.4 Redis哨兵模式的工作方式

1. 每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。
2. 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）
3. 如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态
4. 当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）
5. 在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。
6. 当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
7. 若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。

2.5 Redis哨兵模式的优缺点

优点：

1. 哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。
2. 主从可以自动切换（自动化故障恢复），系统更健壮，可用性更高。

缺点：

1. Redis较难支持在线动态扩容，在集群容量达到上限时在线扩容会变得很复杂。
2. Redis 数据节点中 slave 节点作为备份节点不提供服务

3、集群(Cluster)

Redis 的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台 Redis 服务器都存储相同的数据，浪费内存且有木桶效应，所以在redis3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的内容。

Redis Cluster是社区版推出的Redis分布式集群解决方案，主要解决Redis分布式方面的需求，比如，当遇到单机内存，并发和流量等瓶颈的时候，Redis Cluster能起到很好的负载均衡的目的。

Redis Cluster着眼于提高并发量。集群至少需要3主3从，且每个实例使用不同的配置文件，主从不用配置，集群会自己选。

在redis-cluster架构中，redis-master节点一般用于接收读写，而redis-slave节点则一般只用于备份， 其与对应的master拥有相同的slot集合，若某个redis-master意外失效，则再将其对应的slave进行升级为临时redis-master。

当有请求是在向slave发起时，会直接重定向到对应key所在的master来处理。 但如果不介意读取的是redis-cluster中有可能过期的数据并且对写请求不感兴趣时，则亦可通过readonly命令，将slave设置成可读，然后通过slave获取相关的key，达到读写分离。具体可以参阅redis官方文档等相关内容。

3.1 Redis-Cluster集群的配置

使用集群，只需要将每个数据库节点的cluster-enable配置打开即可。根据官方推荐，集群部署至少要 3 台以上的master节点（因为选举投票的机制，所以必须为奇数），最好使用 3 主 3 从六个节点的模式。在测试环境中，只能在一台机器上面开启6个服务实例来模拟。

3.2 Redis-Cluster集群的特点

1. 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
2. 节点的fail是通过集群中超过半数的节点检测失效时才生效。
3. 客户端与 Redis 节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
4. 所有的节点都是一主一从（也可以是一主多从），其中从节点不提供服务，仅作为备用
5. 支持在线增加、删除节点
6. 客户端可以连接任何一个主节点进行读写

3.3 Redis-Cluster集群的工作方式

在 Redis 的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的 Key到达的时候，Redis 会根据 crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

Redis 集群使用数据分片（sharding）而非一致性哈希（consistency hashing）来实现： 一个 Redis 集群包含 16384 个哈希槽（hash slot）， 数据库中的每个键都属于这 16384 个哈希槽的其中一个， 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。

集群中的每个节点负责处理一部分哈希槽。 举个例子， 一个集群可以有三个哈希槽， 其中：

节点 A 负责处理 0 号至 5500 号哈希槽。
节点 B 负责处理 5501 号至 11000 号哈希槽。
节点 C 负责处理 11001 号至 16384 号哈希槽。
这种将哈希槽分布到不同节点的做法使得用户可以很容易地向集群中添加或者删除节点。

为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。

3.4 Redis-Cluster集群的优缺点

优点

1. 解决分布式负载均衡的问题。具体解决方案是分片/虚拟槽slot。
2. 可实现动态扩容
3. P2P模式，无中心化

缺点

1. 为了性能提升，客户端需要缓存路由表信息
2. Slave在集群中充当“冷备”，不能缓解读压力