一.Redis支持的集群方案
- 主从复制模式
- Sentinel(哨兵)模式
- Cluster集群模式
1.1 主从复制模式
1.1.1 主从复制说明
Redis通过配置持久化，可以保证能够在服务器重启的情况下也不会丢失数据，但数据是存储到一台服务器上的，如果这台服务器出现故障，也会导致数据的丢失。
为了避免出现单点故障的问题，这里是将数据库复制多个副本部署到不同的服务器上，这样即使有一台服务器出现故障，其它服务器仍然可以继续提供服务。
这里引入了Redis的复制(replication)功能，来实现当一台数据库的数据更新后，自动将更新的数据同步到其它数据库上。在这种场景下，数据库分为两类，一类是主数据库(master)，一类是从数据库(slave)。主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库。从数据库一般是只读的，接收主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。
1.1.2 架构图
1.1.3 原理
1）从数据库启动成功后，连接主数据库，发送 SYNC 命令；
2）主数据库接收到 SYNC 命令后，开始执行 BGSAVE 命令生成 RDB 文件并使用缓冲区记录此后执行的所有写命令；
3）主数据库 BGSAVE 执行完后，向所有从数据库发送快照文件，并在发送期间继续记录被执行的写命令；
4）从数据库收到快照文件后丢弃所有旧数据，载入收到的快照；
5）主数据库快照发送完毕后开始向从数据库发送缓冲区中的写命令；
6）从数据库完成对快照的载入，开始接收命令请求，并执行来自主数据库缓冲区的写命令；（从数据库初始化完成）
7）主数据库每执行一个写命令就会向从数据库发送相同的写命令，从数据库接收并执行收到的写命令（从数据库初始化完成后的操作）
8）出现断开重连后，2.8之后的版本会将断线期间的命令传给重数据库，增量复制。
9）主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。Redis 的策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。
1.1.4 主从复制优缺点
优点：
- 支持主从复制，主服务器会自动将数据同步到从服务器，可以进行读写分离；
- 为了分载 Master 的读操作压力，Slave 服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成；
- Slave 同样可以接受其它 Slaves 的连接和同步请求，这样可以有效的分载 Master 的同步压力；
- Master Server 是以非阻塞的方式为 Slaves 提供服务。所以在 Master-Slave 同步期间，客户端仍然可以提交查询或修改请求；
- Slave Server 同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据；
缺点： - Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复（也就是要人工介入）；
- 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性；
- 如果多个Slave断线了，需要重启的时候，尽量不要在同一时间段进行重启。因为只要Slave启动，就会发送sync请求和主机全量同步，当多个Slave重启的时候，可能会导致Master IO剧增从而宕机。
- Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂；
1.2 Sentinel(哨兵模式)
1.2.1 哨兵模式说明
上面主从同步/复制的模式，当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这里就需要人工干预，还会造成一段时间内服务不可用。
哨兵是一个独立的进程，其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
这里哨兵的作用如下：
- 通过发送命令，让Redis服务器返回其运行状态，包括主服务器和从服务器。
- 当哨兵监测到master节点宕机，会自动将slave切换为master，然后通过发布订阅模式通知其它的从服务器，修改配置文件，让它们切换主机；
注意：一个哨兵进程对Redis服务器进行监控，也可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
1.2.2 架构图
1.2.3 故障切换的过程
假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行 failover 过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行 failover 操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。
1.2.4 哨兵的工作原理
- 每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的 Master 主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。
- 如果一个实例（instance）距离最后一次有效回复PING命令的时间超过down-after-milliseconds选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）
- 如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态
- 当有足够数量的Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）
- 在一般情况下， 每个Sentinel（哨兵）进程会以每10秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送INFO命令。
- 当Master主服务器被Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的Master主服务器的所有 Slave 从服务器发送INFO命令的频率会从10秒一次改为每秒一次。
- 若没有足够数量的 Sentinel（哨兵）进程同意Master主服务器下线，Master主服务器的客观下线状态就会被移除。若Master主服务器重新向Sentinel（哨兵）进程发送PING命令返回有效回复，Master主服务器的主观下线状态就会被移除。
1.2.5 哨兵模式的优缺点
优点：
- 哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。
- 主从可以自动切换，系统更健壮，可用性更高。
缺点： - Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。
1.3 Cluster集群模式
Redis 的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台 Redis 服务器都存储相同的数据，很浪费内存，所以在 redis3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的内容。
1.3.1 Cluster集群架构
1.3.2 Cluster集群数据分片说明
Redis集群没有使用一致性hash，而是引入了哈希槽【hash slot】的概念。
Redis 集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽。集群的每个节点负责一部分hash槽，举个例子，比如当前集群有3个节点，那么：
- 节点A包含0到5460号哈希槽
- 节点B包含5461到10922号哈希槽
- 节点C包含10923到16383号哈希槽
这种结构很容易添加或者删除节点。比如如果我想新添加个节点D，需要从节点A，B，C中分配部分槽到D上。如果我想移除节点A，需要将A中的槽移到B和C节点上，然后将没有任何槽的A节点从集群中移除即可。由于从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。
在Redis的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的Key到达的时候，Redis会根据CRC16的算法得出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号在0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。
1.3.3 Redis Cluster集群的主从复制模型
为了保证高可用，redis-cluster集群引入了主从复制模型，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点Ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。
1.3.4 Redis Cluster集群的特点
- 所有的Redis节点彼此互联(PING-PONG机制)，内部使用二进制协议优化传输速度和带宽。
- 节点的fail是通过集群中超过半数的节点检测失效时才生效。
- 客户端与Redis节点直连，不需要中间代理层.客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。