Redis主从复制、哨兵模式、分片、集群

概述

Redis是个内存数据库，速度很快，但单台服务器的内存、处理能力都是有限的。如果数据量太大（比如几十GB），单台机器存不下；或者访问量太高（比如每秒几十万次请求），单台机器扛不住。这时候就需要多台Redis一起工作，也就是"集群"相关的技术。

另外，单台机器万一宕机了，数据就没了，服务也停了，所以还需要"备份"和"自动恢复"的机制，这就是主从复制和哨兵模式的作用。

1. 主从复制（Master-Slave Replication）

解决的问题

数据备份 + 分担读压力。

原理

• 选一台Redis当"主库（Master）"，其他的当"从库（Slave）"。
• 主库负责"写操作"（增删改），写完之后会把数据同步给所有从库。
• 从库只能"读操作"，用户查数据就去从库查，主库就不用管那么多读请求了。

例子

就像一个老板（主库）管发号施令（写数据），几个员工（从库）抄录老板的指令（同步数据），客户来咨询（读数据）就找员工，老板专心处理新指令。

好处

• 数据有备份（从库有完整数据），主库挂了，从库能顶上（需要手动切换）。
• 读请求分散到从库，主库压力小了。

2. 哨兵模式（Sentinel）

解决的问题

主从复制的"自动故障转移"（主库挂了不用手动切换）。

原理

• 专门搞几个"哨兵"进程，它们不存数据，就盯着主库和从库的状态。
• 哨兵们会定期给主库、从库发"心跳"，检查它们活没活着。
• 如果主库挂了，哨兵们会投票选一个从库升级成新主库，然后让其他从库去跟新主库同步数据，整个过程自动完成，不用人管。

例子

哨兵就像监控摄像头+自动调度员，盯着老板（主库）和员工（从库）。老板突然晕倒了，摄像头发现后，调度员立刻从员工里选一个当新老板，其他员工改听新老板的。

好处

主库故障时自动恢复，保证服务不中断，比主从复制更可靠。

3. Redis分片（Sharding）

解决的问题

单台Redis内存不够用（比如数据量太大，超过单台机器内存）。

原理

• 把所有数据"拆分成小块"，不同的块存在不同的Redis服务器上。
• 比如按用户ID分片：ID 1-10000存到Redis服务器A，10001-20000存到服务器B，以此类推。
• 客户端查数据时，先算一下这个数据该存在哪台服务器，再去对应的服务器操作。

例子

就像图书馆的书太多，一个书架放不下，就分成多个书架，按书的编号范围放，找书时先看编号属于哪个书架，再去那个书架找。

好处

数据分散存储，突破单台机器的内存限制，同时也能分担读写压力（不同分片在不同机器）。

4. Redis集群（Redis Cluster）

解决的问题

整合分片、主从、故障转移的"一站式方案"。

原理

• 它是Redis官方提供的集群方案，自带分片功能（数据自动分到不同节点），每个分片又有主从复制（主节点负责写，从节点备份+读），还内置了类似哨兵的故障转移机制（主节点挂了，从节点自动顶上）。
• 整个集群有多个"主节点"（每个主节点对应一个分片），每个主节点可以有多个从节点。
• 客户端连接集群时，不用自己算数据该去哪台机器，集群会自动指引。

例子

相当于一个大型图书馆，有多个书架（分片主节点），每个书架有备份书架（从节点），还有管理员（内置哨兵功能）负责监控书架状态，哪个书架倒了，管理员就把备份书架顶上，读者借书时不用自己找书架，管理员会告诉你去哪找。

好处

一站式解决了数据分片、高可用（主从+自动故障转移）、负载均衡的问题，适合大规模数据和高并发场景。

它们的关系总结

• 主从复制：基础的备份和读分担，手动切换主库。
• 哨兵模式：在主从复制之上，加了自动故障转移，更可靠。
• 分片：解决数据量大的问题，把数据拆分到多台机器。
• Redis集群：官方集成了分片、主从、自动故障转移，是最完整的集群方案。

从简单到复杂：主从复制 → 哨兵模式（主从+自动切换） → 分片（解决大数据） → Redis集群（整合所有功能）。

公司实际部署Redis集群的方式

公司里部署Redis集群的方式，会根据业务规模、数据量、可用性要求来定，常见的有几种方案，从简单到复杂都有：

1. 中小公司/业务初期：哨兵模式（主从+哨兵）

适用场景

数据量不算特别大（单主库能存下），但需要高可用（服务不能随便挂），比如日均请求百万级以内。

部署方式

• 1个主库（Master）+ 2个从库（Slave）：主库负责写，从库同步数据并分担读请求。
• 3个哨兵（Sentinel）：单独部署在不同机器上，监控主从状态，主库挂了自动选新主库。
• 机器要求：至少3台服务器（比如主库1台，从库+哨兵混布2台，或5台机器更稳妥）。

例子

电商小平台，商品库存、用户购物车数据量不大，用这套足够。主库挂了，哨兵10秒内就能切换从库顶上，服务几乎不停。

2. 中大型公司/数据量大：Redis Cluster（官方集群）

适用场景

数据量大（单台机器存不下，比如几十GB甚至上百GB），并发高（每秒几万到几十万请求），比如电商大促、社交平台。

部署方式

• 至少3个主节点（每个主节点是一个分片），每个主节点配1-2个从节点（备份+读分担）。比如3主3从（共6台机器），或6主6从（12台），主从分开部署在不同机器。
• 集群自动分片：数据按哈希算法分到不同主节点，客户端不用管分片逻辑。
• 内置高可用：主节点挂了，它的从节点自动升级为主节点，类似哨兵但更集成。

例子

某电商平台，商品数据有50GB，单台机器存不下，就分3个主节点，每个存17GB左右。大促时，读请求分散到从节点，写请求由主节点处理，某台主库挂了，从库自动顶上，不影响下单。

3. 超大规模：Redis Cluster + 代理层（可选）

适用场景

超大规模集群（比如几十上百个节点），或需要更灵活的路由、限流、监控等功能，比如互联网大厂的核心业务。

部署方式

• 基础还是Redis Cluster（多主多从），但在集群前面加一层代理（比如Twemproxy、Codis）。
• 代理的作用：统一入口（客户端只连代理），处理分片路由、负载均衡，甚至加限流、读写分离策略。

例子

某社交App，日活亿级，Redis集群有20个主节点，客户端通过代理连接，代理会根据用户ID计算该访问哪个分片，还能限制单用户的请求频率，保护集群。

部署时的通用注意点

1. 机器隔离

主从节点、哨兵/集群节点尽量部署在不同物理机/虚拟机，避免一台机器挂了多个节点一起挂。

2. 配置优化

• 内存：主库内存别用满（留20%-30%缓冲，避免频繁淘汰数据）。
• 持久化：开AOF+RDB（AOF保证数据不丢，RDB方便快速恢复）。
• 网络：节点间用内网通信，带宽要够（主从同步、集群心跳需要流量）。

3. 监控告警

用Prometheus+Grafana监控节点状态、内存使用率、同步延迟，出问题及时告警（比如主从同步延迟超过10秒、内存使用率超80%）。

4. 扩容准备

Redis Cluster支持在线加节点（新增主从，迁移部分数据过去），提前规划好扩容方案，避免数据量暴增时手忙脚乱。

总结

• 小业务：哨兵模式（简单、够用）。
• 中大规模：Redis Cluster（官方方案，省心）。
• 超大规模：Cluster+代理（更灵活可控）。

核心都是围绕"数据不丢、服务不停、能扛住并发"这三个目标，根据业务体量选合适的方案，没必要一上来就搞最复杂的～