Redis各模式运行方式及优缺点

单机模式

实现方式

1. 只有一个节点需要部署，是最简单的Redis实现方式。# 主从Master/Slave模式

优点

1. 部署简单。
2. 成本低，没有备用节点的开支。
3. 单机不需要同步数据，数据具有天然一致性。

缺点

1. 容灾能力弱，有宕机风险。
2. 性能受限于CPU的处理能力。

主从Master/Slave模式

实现方式

1. 这种模式采用的是一主 N 从的部署方式。其中Slave 节点的作用是作为 Master 节点的数据备份。默认配置下，Master 节点提供读和写功能，Slave 节点只提供读功能（即 readonly ）。
2. Master 节点挂掉以后，Redis 将不再提供写功能，不影响 Slave 节点的读功能。Master 重启后 Redis 将重新对外提供写功能。Slave 节点挂掉以后，不影响 Master 节点的读和写，也不影响其他 Slave 节点的读，该 Slave 重启后，会将数据从 Master 节点同步过来。
3. 当 Master 需要密码时，客服端访问 Master 需要密码，启动 Slave 需要密码，客户端访问 Slave 不需要密码。

优点

1. 可备份数据，提升了容灾能力。任一节点出现故障，不会导致严重的数据丢失。
2. 从节点可以分担主节点的读压力。

缺点

1. 当 Master 节点挂掉后，Slave 并不会自动接替成为新的 Master，Redis 不能提供写功能，只剩下从节点的读功能。
2. 需要管理员人工干预，修改应用方的主节点地址，命令所有从节点去复制新的主节点。
3. 整个服务的写能力受到主节点单机的限制。
4. 整个服务的存储能力受到单机的限制。

哨兵Sentinel模式

实现方式

1. 主从模式解决了节点宕机可能导致数据丢失的问题，但是没有实现自动化的故障修复。哨兵模式在此基础上添加了一个或多个Sentinel节点（哨兵节点是特殊的Redis节点，不存储数据），用于监控所有的主节点、从节点、其他Sentinel实例。

2. 当 Master 节点挂掉后，Sentinel 会从 Slave 节点中选举一个出来作为新的 Master 节点，保证 Redis 的写功能正常。其他的 Slave 节点配置文件也会指向新的 Master。而之前挂掉的 Master 节点重启后，会成为一个 Slave 节点，接收新的 Master 节点的同步数据。

3. 在使用 Sentinel 模式时，客户端不用直接连接 Redis，而是连接 Sentinel的 ip 和 port，由 Sentinel 来提供正常提供服务的 Redis。这样即使 Master 节点挂掉，客户端也不会感知。

4. 监控原理：
   （１）每个Sentinel以每1秒1次的频率，向所有的主服务器、从服务器以及其他Sentinel实例发送一个PING命令。
   （２）如果一个实例距离最后一次有效回复PING命令的时间超过down-after-milliseconds所指定的值，那么这个实例会被Sentinel标记为主观下线。
   （３）如果一个主服务器被标记为主观下线，那么正在监视这个主服务器的的所有Sentinel节点，要以1次/s的频率确认该主服务器是否确实进入了主观下线状态。如果有足够数量（达到配置文件中指定的数量）的Sentinel在指定的时间范围内同意该判断，那么这个主服务器被标记为客观下线。
   （４）一般情况下，每个Sentinel以每10秒1次的频率，向它已知的所有主服务器和从服务器发送INFO命令。
   （５）当一个主服务器被Sentinel标记为客观下线时，Sentinel向下线的主服务器的所有从服务器发送INFO命令的频率会提高至10倍，即每1秒1次。
   （６）多个Sentinel会协商主节点的状态，如果主节点处于SDOWN状态，则投票自动选出新的主节点，将剩余的从节点指向新的主节点进行数据复制。
   （７）当没有足够数量的Sentinel同意主服务器下线时，主服务器的客观下线状态就会被移除。当主服务器重新向Sentinel的PING命令返回有效回复时，主服务器的主观下线状态就会被移除。
   

5. Sentinel 集群：
   （１）由于 Sentinel 有挂掉的风险，可以启动多个 Sentinel 来形成 Sentinel 集群。客户端可以任意连接一个 Sentinel 来获得 Redis 集群的信息。
   （２）一个 Sentinel 或者集群可以管理多个主从 Redis。
   （３）与其他集群不同，无需设置其他 Sentinel 的地址。Sentinel 进程可以通过发布与订阅来自动发现正在监视相同主实例的其它 Sentinel。当一个 Sentinel 发现一个新的 Sentinel 时，会将其添加到一个列表中。这个列表中保存了 Sentinel 一致的，监视同一个主服务的所有其他 Sentinel。
   （４）Sentinel 集群中的 Sentinel 不会在同一时刻去 failover（故障转移）同一个 Master。当第一个 Sentinel 执行失败后，另一个才会重新进行 failover。当执行成功后，它将会把关于 Master 的最新配置通过广播形式通知其他 Sentinel。

优点

1. Sentinel模式是基于主从模式的，所有主从模式的优点，Sentinel模式都具有。
2. 在 Master 挂掉的情况下，能自动选举出新的 Master，保证生产环境的稳定。
3. Sentinel会不断检查主服务器和从服务器是否正常运行。当某个服务器出现问题时，Sentinel可以通过API脚本向管理员或者其他的应用程序发送通知。

缺点

1. 当数据量过大，一台服务器存放不下的情况时，不能满足需求。（此时需要采用Cluster模式对存储的数据进行分片，将数据存放到多个Redis实例中）
2. 当读写访问频率过高，高并发的情况下，对CPU资源消耗不大，但内存会达到瓶颈。

集群Cluster模式

实现方式

1. 主从模式和哨兵模式都没有解决一个问题：单个节点的存储能力是有上限的，访问能力也是有上线的。而Cluster集群模式具有高可用、可扩展性、分布式、容错等特性。
2. Cluster模式通过数据分片的方式来进行数据共享，同时提供数据复制和故障转移功能。
3. 结构：集群中包含至少 3 个节点组，每个节点组都有 1 到 N 个节点，其中 1 个主节点和 N-1 个从节点。
4. 一个 Redis 集群包含 16384 个哈希槽（hash slot），数据库中的每个键都属于这 16384 个哈希槽的其中一个，集群中的每个节点负责处理一部分哈希槽。
5. 集群扩/缩容：
   （１）Redis集群扩容后，哈希槽数不变，仍然是16384个。增加节点后，槽需要重新分配，数据也需要重新迁移，但是服务不需要下线。
   （２）重新分片操作由Redis内部的管理软件redis-trib负责执行，Redis提供了进行重新分片的所有命令，redis-trib通过向节点发送命令来进行重新分片。
   （３）如果用户将新节点 D 添加到集群中，只需要将 A、B、C 中某些槽移动到节点 D 中就可以了。
   （４）如果用户要从集群中移除节点 A，只需要将节点 A 中的所有哈希槽移动到节点 B、C 中，然后移除空白的节点 A 就可以了。
6. 主节点挂掉时，从节点会通过心跳监听机制，竞选成为主节点，所以在部署时，主从节点应当部署在不同的机器上。
7. Redis 集群中的节点通过 gossip 协议通信。
8. 当前 Redis 集群不支持 NAT 环境或者 IP、端口重新映射的环境。

优点

1. 解决了哨兵模式不能扩展存储能力的缺点。

缺点

1. 需要机器较多。部署方式是最复杂的一种。当数据量不是很大时，可以只用 Sentinel 哨兵模式。