Redis单机、主从、哨兵、集群模式

单机模式

就是安装一个redis，启动起来，业务调用即可。
单机在很多场景也是有使用的，例如在一个并非必须保证高可用的情况下。

优点

• 部署简单，0成本；
• 成本低，没有备用节点，不需要其他的开支；
• 高性能，单机不需要同步数据，数据天然一致性。

缺点

• 可靠性保证不好，单节点有宕机的风险；
• 单机高性能受限于CPU的处理能力，redis是单线程的；
• 单机模式选择需要根据自己的业务场景去选择，如果需要很高的性能、可靠性，单机就不合适了。

主从复制模式

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。
前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，主从复制支持 主从同步 和 从从同步 两种，后者是 Redis 后续版本新增的功能，以减轻主节点的同步负担。

优点

• 数据冗余： 主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
• 故障恢复： 当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复。
• 负载均衡： 在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务 （即-写 Redis 数据时应用连接主节点，读 Redis 数据时应用连接从节点），分担服务器负载。尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高 Redis 服务器的并发量。
• 高可用基石： 除了上述作用以外，主从复制还是哨兵和集群能够实施的 基础，因此说主从复制是 Redis 高可用的基础。

缺点

• 数据冗余带来额外开销。
• 一旦主节点宕机，从节点晋升成主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去 复制新的主节点，整个过程需要 人工干预。
• 主节点的写能力受到单机的限制。
• 主节点的存储能力受到单机的限制。

主从同步流程

第一次同步时，主节点做一次bgsave，并同时将后续修改操作记录到内存缓冲区，待完成后将RDB文件全量同步到复制节点，复制节点接受完成后将RDB镜像加载到内存。
加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。
后续的增量数据通过AOF日志同步即可，有点类似数据库的binlog。

哨兵模式

主从模式下，主节点出现问题，从节点依然能提供读服务，但不能自动升级为主节点，不能实现故障自动化恢复。
Redis Sentinal 着眼于高可用，在master宕机时会自动将slave提升为master，继续提供服务。

原理

• 哨兵节点： 哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的 Redis 节点，不存储数据；
• 数据节点： 主节点和从节点都是数据节点；

在复制的基础上，哨兵实现了 自动化的故障恢复 功能，下方是官方对于哨兵功能的描述：

• 监控（Monitoring）： 哨兵会不断地检查主节点和从节点是否运作正常。
• 自动故障转移（Automatic failover）： 当 主节点 不能正常工作时，哨兵会开始 自动故障转移操作，它会将失效主节点的其中一个 从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
• 配置提供者（Configuration provider）： 客户端在初始化时，通过连接哨兵来获得当前 Redis 服务的主节点地址。
• 通知（Notification）： 哨兵可以将故障转移的结果发送给客户端。

其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移。而配置提供者和通知功能，则需要在与客户端的交互中才能体现。

实际规模

一般至少3个哨兵节点，3个主从节点才可以保证高可用。

优点

• 哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。
• 主从可以自动切换，系统更健壮，可用性更高。
• Sentinel 会不断的检查 主服务器 和 从服务器 是否正常运行。当被监控的某个 Redis 服务器出现问题，Sentinel 通过API脚本向管理员或者其他的应用程序发送通知。

缺点

• Redis较难支持在线扩容，对于集群，容量达到上限时在线扩容会变得很复杂。

集群模式

主从和哨兵都还有另外一些问题没有解决，单个节点的存储能力是有上限，访问能力是有上限的。
Redis Cluster 集群模式具有高可用、可扩展性、分布式、容错等特性。

原理

• 通过数据分片的方式来进行数据共享问题，同时提供数据复制和故障转移功能。
• 之前的两种模式数据都是在一个节点上的，单个节点存储是存在上限的。集群模式就是把数据进行分片存储，当一个分片数据达到上限的时候，就分成多个分片。

数据分片

集群的键空间被分割为16384个slots（即hash槽），通过hash的方式将数据分到不同的分片上的。

HASH_SLOT = CRC16(key) & 16384 

读请求分配给slave节点，写请求分配给master，数据同步从master到slave节点。
读写分离提高并发能力，增加高性能。

数据分区方式 - 带有虚拟节点(槽)的一致性哈希分区

该方案在 一致性哈希分区的基础上，引入了 虚拟节点 的概念。Redis 集群使用的便是该方案，其中的虚拟节点称为 槽（slot）。槽是介于数据和实际节点之间的虚拟概念，每个实际节点包含一定数量的槽，每个槽包含哈希值在一定范围内的数据。

在使用了槽的一致性哈希分区中，槽是数据管理和迁移的基本单位。槽解耦了数据和实际节点 之间的关系，增加或删除节点对系统的影响很小。系统中有 4 个实际节点，假设为其分配 16 个槽(0-15)；

槽 0-3 位于 node1；4-7 位于 node2；以此类推....
如果此时删除 node2，只需要将槽 4-7 重新分配即可，例如槽 4-5 分配给 node1，槽 6 分配给 node3，槽 7 分配给 node4；可以看出删除 node2 后，数据在其他节点的分布仍然较为均衡。

因此，集群模式可以对Redis节点做动态伸缩。