Redis集群那些事儿，聊聊几种模式和它们咋用

说到Redis集群,其实就是为了解决两个核心问题：一是数据量太大，一台机器存不下怎么办（数据扩展性问题）；二是一台机器挂了，服务就全停了怎么办（高可用问题），围绕这两个问题，就诞生了不同的“玩法”或者说模式，咱们就来聊聊最常见的几种。

第一种模式：主从复制

这是最基础、最简单的一种模式，主要解决的是高可用和读性能的问题，它的结构就像一个“大哥”带着几个“小弟”。

• 怎么玩： 你设定一台Redis服务器作为“主节点”，它负责处理所有的写操作，你可以配置一台或多台服务器作为“从节点”，从节点启动后，会从主节点那里把全部数据复制一份过来，之后主节点有任何数据变化，也会实时同步给从节点，这样一来，从节点上的数据和主节点是完全一样的。
• 有啥用：
  1. 数据备份： 从节点就是主节点的完整备份，万一主节点宕机了，从节点上还有一份数据，不至于全军覆没。
  2. 读写分离： 所有的写操作必须交给主节点，但读操作可以分散到各个从节点上去，这样就像多了几个帮手专门处理读请求，大大减轻了主节点的压力，提升了整体的读性能。
• 缺点： 它没能解决最根本的数据扩展性问题，因为所有的写操作还是集中在一台主节点上，如果写操作非常频繁，主节点还是会成为瓶颈，如果主节点真的挂了，需要手动把一个从节点“提拔”成新的主节点，这个过程不是自动的，服务会中断一段时间。

第二种模式：哨兵模式

哨兵模式是在主从复制基础上的一次重要升级,它解决了主从模式“主节点挂了需要手动干预”的痛点，实现了自动化的高可用。

• 怎么玩： 除了主节点和从节点之外，我们额外启动几个独立的“哨兵”进程，这些哨兵不存储数据，它们的任务就像一群侦察兵，时时刻刻监视着主节点和从节点是否在正常工作，它们会定期向所有节点发送心跳包检查健康状况，如果多数哨兵都认为主节点“失联”了，它们就会自动协商，选举出一个从节点，把它升级为新的主节点，然后通知其他的从节点和客户端这个变化。
• 有啥用：
  1. 自动故障转移： 这是核心价值，主节点宕机后，无需人工插手，系统能在几十秒内自动完成切换，恢复服务，大大提高了系统的可用性。
  2. 监控提醒： 哨兵会持续监控整个集群的状态，出问题时可以发送通知给管理员。
• 缺点： 哨兵模式依然没有解决写操作的单点瓶颈和单机存储容量有限的问题，数据还是只能存在一个主节点上，只是保证了主节点挂了能自动换人。

第三种模式：Redis Cluster（官方集群模式）

这是Redis官方推出的“终极”解决方案，它同时解决了高可用和数据分片（就是把大数据拆成小块分散存储）这两个核心问题。

• 怎么玩： 这种模式下，没有传统意义上的中心主节点了，它把整个数据集自动划分成16384个“槽位”，你需要至少启动三个主节点（官方建议是三主三从），这些槽位会大致平均地分配给这些主节点，每个主节点负责一部分数据，键为“user:001”的数据，会根据一个算法被映射到某个槽位，进而存储到负责这个槽位的那个主节点上，每个主节点都会配备一个或多个从节点，作为它的备份。
• 有啥用：
  1. 真正的数据分片： 数据被分散存储在多个主节点上，突破了单机内存的限制，可以实现海量数据存储，写操作也被分摊了，解决了性能瓶颈。
  2. 高可用： 和哨兵模式类似，如果某个主节点挂了，它下属的从节点会自动被提升为新主节点，继续提供服务，整个过程是自动的。
• 缺点： 配置和管理比前两种模式要复杂一些，客户端也需要支持Cluster协议，才能正确地路由请求到正确的节点上，它不支持需要同时操作多个键的命令（除非这些键在同一个槽位里），这在设计数据模型时需要留意。

总结一下

• 主从复制像是打基础，适合读多写少、对高可用要求不极致的场景。
• 哨兵模式在主从基础上加了“自动故障切换”，适合对可用性要求高，但数据量还没大到需要分片的场景。
• Redis Cluster是集大成者，适合数据量巨大、并发要求高的生产环境，是支撑大型应用的首选。

选择哪种模式,完全取决于你的业务场景：数据量有多大、读写比例如何、对高可用的要求有多高，没有最好的，只有最合适的。 参考了Redis官方文档、以及技术社区如菜鸟教程、CSDN、掘金等平台上关于Redis集群架构的普遍解读和总结）