Redis主从复制+哨兵架构详解：高可用方案实战

1. 方案选型与整体设计思路

先说结论：如果你正在维护一个流量不大不小、对数据一致性要求较高、又不想直接上Cluster模式（集群模式）的业务系统，那么"主从复制 + 哨兵（Sentinel）"这套组合，基本就是性价比最高的高可用方案了。

我在实际项目里见过不少朋友一上来就奔着Redis Cluster去，结果发现槽位分配、多键操作限制、客户端升级这些连带改动一大堆，反而把自己搞得很痛苦。其实在很多场景下，主从加哨兵已经能解决90%的高可用问题——主库挂了自动切换，从库分担读压力，数据有冗余备份，配置和维护成本都远低于Cluster。这里先把这个方案的核心逻辑讲清楚，后面再一步步带你搭起来。

1.1 为什么是主从+哨兵，而不是其他方案

先看几张常见架构的对比：

单机Redis自不必说，宕机直接全盘不可用。纯主从复制虽然有了数据冗余，但主库故障时从库不会自动上位，你得半夜爬起来手动执行命令切换，这中间的业务中断时间完全不可控。而Cluster模式虽然扩展性最强，但它引入了数据分片的概念，槽位（slot）分布在多个节点上，多键操作受到限制，很多已有业务代码需要改造。

主从+哨兵这套方案，本质上是在"主从复制"的基础上增加了一层"监督者"。哨兵节点负责监控所有Redis节点的健康状态，当主节点出现故障时，哨兵集群通过投票机制选举出新的主节点，并自动把其他从节点的主库指向切换过去。整个过程不需要人工干预，业务方只需要连接哨兵节点获取当前主库地址即可。

1.2 这套方案适合什么业务场景

根据我的经验，这几类场景特别适合主从+哨兵：

第一类是读多写少的业务。比如内容管理系统、商品详情页缓存、配置中心等，读请求远多于写请求。通过主从复制可以把读流量分散到多个从库上，主库只负责写，Redis的QPS能翻好几倍。

第二类是数据量可控但要求高可用的业务。比如用户会话信息、订单状态缓存、实时排行榜等，这些数据量通常在几GB到几十GB之间，单机内存够用，不需要分片，但宕机几分钟都是不可接受的。

第三类是已有单机Redis想平滑升级的业务。从一个节点升级成主从+哨兵，不需要改动业务代码，客户端连接方式从直连Redis改为连接哨兵服务，或者使用支持哨兵的客户端连接池即可，迁移成本很低。

如果你已经确定这套方案适合你，那就可以开始动手了。后面我以一个三节点环境为例，完整演示从零到一搭建主从复制和哨兵集群的全过程，包含每一步的配置文件、命令、验证方法和踩坑记录。

2. 主从复制搭建全流程

主从复制是整个高可用方案的基础，哨兵只是在主从基础上做自动故障转移。所以先把主从复制搭好，搭的过程中理解它的工作原理，后面配置哨兵就会很顺。

2.1 环境准备与Redis安装

这里我用三台Linux服务器为例，分别称为节点A、节点B、节点C。实际生产环境中，节点最好分布在不同机架或不同可用区，避免物理层面的单点故障。测试环境用一台机器开三个实例也可以，但生产环境强烈建议物理隔离。

先确认系统版本和依赖：

cat /etc/os-release # 以 CentOS 7/8 或 Ubuntu 18.04/20.04 为例 # 安装基础依赖 yum install -y gcc gcc-c++ make tcl # CentOS # apt-get install -y build-essential tcl # Ubuntu

Redis的安装我推荐用源码编译安装，虽然比包管理器多几步，但好处是版本可控、参数可定制。这里用 Redis 6.x 版本演示，稳定性和功能都经过了生产环境验证。

# 下载源码包（在 /usr/local/src 下操作） cd /usr/local/src wget https://download.redis.io/releases/redis-6.2.14.tar.gz tar xzf redis-6.2.14.tar.gz cd redis-6.2.14 # 编译安装 make -j4 make install PREFIX=/usr/local/redis # 添加环境变量 echo 'export PATH=/usr/local/redis/bin:$PATH' >> /etc/profile source /etc/profile

装完后先验证一下：

redis-server -v # Redis server v=6.2.14 sha=00000000:0 malloc=libc bits=64 build=xxx

三个节点都重复上述操作，把Redis基础环境准备好。在生产环境里我一般还会顺手做个systemd服务脚本，方便开机自启和统一管理，后面如果你需要也可以加上。

2.2 主节点配置详解

进入Redis安装目录下的配置文件目录，开始配置主节点。核心配置项如下：

# 在 /usr/local/redis/etc/redis.conf 中修改 # 绑定地址，生产环境根据实际内网IP修改 bind 0.0.0.0 # 端口号，保持默认或自定义，生产环境建议别用默认6379，避免被扫描 port 6379 # 守护进程模式 daemonize yes # PID文件和日志文件位置 pidfile /var/run/redis_6379.pid logfile "/var/log/redis_6379.log" # 数据持久化，主从场景建议AOF和RDB同时开启 appendonly yes appendfilename "appendonly.aof" appendfsync everysec # 设置密码（生产环境强烈建议） requirepass your_redis_password # 如果不设置密码，至少要做内网访问控制 protected-mode yes

这里重点说几个容易被忽视的配置项：

daemonize yes是把Redis放到后台运行，否则你一关终端Redis就跟着停了。appendonly yes是开启AOF持久化，主从复制场景下，从节点的数据最终来自主节点的持久化文件，主节点如果持久化没做好，崩溃恢复后数据本身就是旧的，复制给从库也是错的。requirepass用于设置认证密码，主从复制时从库要用这个密码连接主库，哨兵也要用它来访问Redis实例。

配置好后启动主节点：

/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf

验证是否启动成功：

redis-cli -a your_redis_password ping # PONG

2.3 从节点配置与主从关系建立

从节点的配置和主节点基本相同，但有几个关键差异点。以节点B为例：

# 修改 /usr/local/redis/etc/redis.conf bind 0.0.0.0 port 6379 daemonize yes pidfile /var/run/redis_6379.pid logfile "/var/log/redis_6379.log" appendonly yes appendfilename "appendonly.aof" appendfsync everysec requirepass your_redis_password # 关键：指定主节点地址和端口 replicaof 192.168.1.10 6379 # 主节点设置了密码，这里要配上 masterauth your_redis_password

在Redis 5.0之前的版本中，这个参数叫slaveof，从Redis 5.0开始官方建议使用replicaof，语义更准确。如果你的业务代码里有通过SLAVEOF命令动态切换主库的脚本，注意在新版本中对应的是REPLICAOF命令。

这里也可以不修改配置文件，通过命令行动态设置从主关系，但不推荐，因为重启服务器之后会丢失：

redis-cli -a your_redis_password replicaof 192.168.1.10 6379

配置好后启动从节点B：

/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf

然后分别在三个节点上检查复制状态：

# 在主节点A上查看从库信息 redis-cli -a your_redis_password info replication

在主节点上预期看到类似这样的输出：

# Replication role:master connected_slaves:1 slave0:ip=192.168.1.11,port=6379,state=online,offset=1556,lag=0

state=online表示从节点已经是在线同步状态，offset是已经同步的字节偏移量。

在从节点B上执行同样命令，预期输出会是：

role:slave master_host:192.168.1.10 master_port:6379 master_link_status:up slave_read_only:1 offset:1556

看到master_link_status:up就说明主从链路已经建立，数据正在同步。slave_read_only:1表示从节点默认只读，这个默认配置很重要，防止脏数据写入从库造成主从数据不一致。

2.4 主从复制的核心机制与参数调优

主从复制底层机制很多人搞不清楚，其实整个流程可以拆成三个阶段，理解了它你排查问题会快很多。

第一阶段是建立连接和握手。从节点向主节点发送PSYNC命令，传递自己的复制ID和偏移量。如果是第一次复制，复制ID未知，主节点会触发全量复制。

第二阶段是全量复制。主节点执行BGSAVE生成RDB快照文件，同时用缓冲区记录后续的写命令。RDB文件生成后通过网络发给从节点，从节点清空旧数据，加载RDB文件。同步完成后，主节点把缓冲区的写命令继续发给从节点。

第三阶段是增量同步。主节点把每一次写命令通过传输协议实时转发给从节点，从节点执行相同的命令，最终达到数据一致。整个过程基于偏移量offset来对齐，从节点每执行一条命令都会更新自己的offset，并在心跳中回报给主节点。

全量复制会遇到一个经典的生产问题：如果从节点和主节点的数据差距很大，RDB文件传输又慢，缓冲区设置不合理，就可能导致同步循环或者数据一直追不上。

关键的调优参数有三个：

# 主节点上设置复制缓冲区大小 repl-backlog-size 128mb # 从节点上设置全量复制超时时间 repl-timeout 120 # 从节点向主节点发送心跳的间隔 repl-ping-replica-period 10

repl-backlog-size是主节点用来保存写命令的环形缓冲区。如果网络抖动导致从节点短暂断连，靠这个缓冲区可以实现增量续传，而不是重新全量复制。这个值设得太小，断线时间稍长就得重新全量同步，代价很大。我曾见过有人默认1MB没改，主库一写多就从库掉线重连，反复全量复制把主库IO打满。建议至少128MB起步，如果单节点写命令多，直接上256MB。

repl-timeout是从节点判断主节点是否超时的依据，如果60秒内没有收到主节点的心跳或数据，从节点会判定连接超时。在网络环境复杂的场景，适当调大这个值可以减少误判。但注意它和哨兵的down-after-milliseconds是独立的，后面会讲到。

repl-ping-replica-period控制从节点向主节点发送心跳的间隔，默认10秒。在主从链路稳定的情况下，一般不用改。但如果你的网络设备对空闲连接有自动回收策略，可以稍微调小到5秒，避免长连接被中间设备断开后要等很久才被发现。

2.5 读写分离与从节点只读保护

主从复制建好后，很自然的一个用法就是读写分离。写操作走主节点，读操作走从节点。

一个容易被忽略的细节是：从节点默认开启了只读模式（slave-read-only yes），这是一个非常安全的设计。但如果你用管理账号对从节点执行了写操作，Redis 6.x虽然会拒绝，但如果你通过某些客户端工具配置了错误的主从地址，写请求被路由到了从节点，只读模式的保护就很重要了。

如果在从节点上强制写入，会报这样的错误：

(error) READONLY You can't write against a read only replica.

另外，从节点在处理读请求时，由于主从之间存在同步延迟，可能会有短暂的数据不一致。解决这个问题的思路有两种：一种是在业务代码中识别强实时性数据，全部走主库读；另一种是使用WAIT命令确认从节点已经同步到指定偏移量再读。后者性能损耗比较大，一般只在金融类交易场景中使用。

到这里，一个基础的主从复制集群已经搭建完成。但说实话，到了这一步还远没有达到"高可用"——主节点宕机了，从节点虽然数据还在，但不会自动上位，业务写入全部会失败。这就是为什么还需要哨兵。

3. 哨兵模式部署与故障转移

哨兵（Sentinel）在Redis高可用架构里充当的是"监督者+决策者"的角色。它的职责可以概括为三件事：监控、通知、自动故障转移。

哨兵本身也是Redis服务器，只不过它运行在特殊模式下，不存储业务数据，而是专门负责监控其他Redis实例的健康状态。生产环境至少部署3个哨兵节点，形成一个哨兵集群，这样既避免单点故障，又能在主节点宕机时通过投票机制达成一致，选出新的主节点。

3.1 哨兵的三种角色与工作模式

哨兵集群内部有几类角色：

• 哨兵节点（Sentinel）：监控Redis主从节点，以及监控其他哨兵节点。
• 主节点（Master）：提供写服务的Redis实例。
• 从节点（Replica）：提供读服务的Redis实例。

哨兵之间通过发布/订阅频道通信，它们会周期性地向所有被监控的Redis节点发送命令，检查对方是否正常响应。当某个哨兵发现主节点无法响应时，它不会立刻宣布主节点下线——毕竟网络抖动可能导致误判，它首先要征求其他哨兵的意见。

这里有两个关键概念：

主观下线（Subjectively Down，SDOWN）：单个哨兵认为主节点下线了。客观下线（Objectively Down，ODOWN）：达到指定数量（quorum）的哨兵都认为主节点下线了。

当一个主节点被判断为客观下线后，哨兵集群就开始执行故障转移：从现有的从节点中，根据一定规则选出一个新的主节点，然后通知所有其他从节点将新主节点设为它们的主库。

3.2 哨兵配置文件详解

以节点A为例，创建一个独立的哨兵配置文件。哨兵配置文件的路径和Redis配置文件分开，内容也要单独写：

vim /usr/local/redis/etc/sentinel.conf

核心配置项如下：

# 哨兵监听端口 port 26379 # 守护进程模式 daemonize yes # 日志文件 logfile "/var/log/redis_sentinel.log" # 监控的主节点名称、IP、端口、投票法定数 sentinel monitor mymaster 192.168.1.10 6379 2 # 主节点密码 sentinel auth-pass mymaster your_redis_password # 主节点判定下线的超时时间（毫秒） sentinel down-after-milliseconds mymaster 5000 # 故障转移超时时间（毫秒） sentinel failover-timeout mymaster 15000 # 故障转移后同时向新主节点发起同步的从节点数量 sentinel parallel-syncs mymaster 1

逐项解释一下：

sentinel monitor mymaster 192.168.1.10 6379 2是哨兵配置里最核心的一行。mymaster是这个主节点组在哨兵配置中的逻辑名称，你可以随意命名，但要保证三个哨兵配置里的一致性；2是 quorum，意思是至少需要2个哨兵同意才能判定主节点客观下线。

quorum 的取值需要根据哨兵总数来定：总共3个哨兵，quorum设为2；总共5个哨兵，quorum设为3。它的含义是"达成一致意见的最少哨兵数量"，取值为哨兵总数的一半以上即可。

sentinel down-after-milliseconds是哨兵判断某个节点是否下线的超时时间。5000毫秒意味着一个哨兵如果在5秒内无法与主节点正常通信，就会给该节点标记为主观下线。这个值不宜设得太小，否则网络抖动就会频繁触发故障转移；也不宜设得太大，否则故障恢复时间太长。我在生产环境一般设为10秒左右。

sentinel parallel-syncs控制故障转移后，最多有多少个从节点可以同时向新主节点发起同步。设置为1意味着逐个同步，避免多个从节点同时全量复制把新主节点的带宽和IO打爆。

sentinel failover-timeout是故障转移的超时时间，包括检测到主节点客观下线、选举新主节点、通知所有从节点切换主库的整个过程。设置太短可能导致同步未完成就触发新的选举，设置太长则会导致恢复时间变长。

三个节点都需要配置这份哨兵文件，唯一不同的可能是sentinel monitor行里的地址，要统一指向最初的主节点地址。注意，即使和哨兵部署在同一台机器上，哨兵配置和Redis实例配置也要分开文件管理。

启动哨兵：

/usr/local/redis/bin/redis-sentinel /usr/local/redis/etc/sentinel.conf

启动后验证哨兵状态：

redis-cli -p 26379 sentinel master mymaster # 输出结果中包含主节点的地址、端口、状态等信息 redis-cli -p 26379 sentinel replicas mymaster # 显示被监控的从节点列表 redis-cli -p 26379 sentinel sentinels mymaster # 显示其他哨兵节点的信息

当看到主节点状态为sdown或odown之外的正常状态，并且从节点信息正常显示时，哨兵集群就算部署成功了。

3.3 故障转移的完整流程拆解

理解故障转移的执行过程，对排查问题会很有帮助。整个过程可以拆成几个步骤：

第一步，哨兵节点通过心跳检测发现主节点异常。每个哨兵每秒向主节点发送一次PING命令，如果在down-after-milliseconds指定的时间内没有得到有效回复，该哨兵会标记主节点为主观下线（SDOWN）。

第二步，主观下线的哨兵会通过发布/订阅频道向其他哨兵广播这一消息，并请求其他哨兵确认。其他哨兵在收到请求后，也会检查自己与主节点的连接状态。当同意主节点下线的哨兵数量达到quorum阈值时，该主节点被标记为客观下线（ODOWN）。

这一步有个容易误判的情况：主节点所在服务器负载极高，导致Redis进程无法及时响应PING，但进程其实没有崩溃。此时如果没有合理的超时设置，可能会触发无意义的故障转移。所以我才建议在生产环境把down-after-milliseconds设置在5到10秒之间，太灵敏反而是灾难。

第三步，确认客观下线后，哨兵集群开始选举领导者。这个选举过程用的是Raft算法类似的思想：每个哨兵都有投票权，拥有从节点投票数最多的哨兵将成为执行故障转移的领导者。多个哨兵之间通过消息交互达成共识，保证了同一时刻只有一个哨兵在执行故障转移，避免两个哨兵同时把不同的从节点提升为主节点。

第四步，领导者哨兵从当前所有健康的从节点中选出一个新的主节点。选择规则优先级如下：

简单来说，优先选择数据最完整的从节点；如果数据完整度相同，选配置优先级最高的；如果还相同，就选运行ID最小的。这里的replica-priority可以在从节点配置文件里设置，你可以把某些硬件更好的从节点的优先级调低（比如设成50），让它在选举中更占优势。

第五步，新主节点确定后，哨兵会向它发送SLAVEOF NO ONE命令，让它脱离主从关系，成为新的主节点，并将旧主节点的配置覆盖掉。

第六步，哨兵向其他所有从节点发送SLAVEOF 新主节点IP 新主节点端口命令，让它们重新指向新主节点，开始同步新主节点的数据。

第七步，旧主节点如果恢复了，哨兵也会将其配置为从节点，指向新主节点，保证整个集群的收敛。

3.4 Sentinel与Redis实例的连接机制

哨兵除了要监控Redis实例，还要能和Redis实例进行认证和数据交互。如果你的Redis设置了密码，必须注意哨兵配置的两个认证点：

第一个是前面的sentinel auth-pass mymaster your_redis_password，这是哨兵连接主节点和从节点的密码。每台被监控的Redis节点密码都需要保持一致，否则哨兵无法完成监控。

第二个是哨兵节点之间的通信。哨兵之间通过sentinel协议而不是普通Redis客户端协议通信，因此哨兵之间的连接不依赖于requirepass。但如果哨兵配置文件里也设置了requirepass，哨兵间就要用sentinel auth-pass来加密码，一般不推荐这么做，会增加故障转移期间的复杂度。

另外要注意，如果你的主从节点设置了不同的密码，或者某个从节点单独设置了另一个密码，哨兵配置里要分别指定。哨兵识别从节点的时候，会对每个从节点单独发起认证，认证失败则该从节点不会被纳入故障转移候选列表。

3.5 手动验证故障转移效果

搭建完成后，一定要手动做一次故障演练，验证哨兵能不能自动完成主从切换。我在生产环境每次变更后都会做一次，确保不是纸上谈兵。

模拟主节点宕机：

# 在节点A上直接杀掉Redis主进程 kill -9 $(cat /var/run/redis_6379.pid)

然后等待5秒（down-after-milliseconds），再观察哨兵日志：

tail -f /var/log/redis_sentinel.log

预期看到类似这样的日志：

+ sdown master mymaster 192.168.1.10 6379 + odown master mymaster 192.168.1.10 6379 #quorum 2/2 + new-epoch 1 + try-failover master mymaster 192.168.1.10 6379 + vote-for-leader 8f7d3c2a5b1e460ea1f23456789abcdef 1 + elected-leader 8f7d3c2a5b1e460ea1f23456789abcdef + failover-state-select-slave master mymaster 192.168.1.10 6379 + selected-slave 192.168.1.11:6379 + failover-state-send-slaveof-noone slave 192.168.1.11:6379 + failover-state-wait-promote slave 192.168.1.11:6379 + promoted-slave 192.168.1.11:6379 + failover-state-reconf-slave master mymaster 192.168.1.11:6379 + slave-reconf-sent slave 192.168.1.11:6379 + failover-end master mymaster 192.168.1.11:6379 + switch-master mymaster 192.168.1.10 6379 192.168.1.11 6379

日志里的关键节点是selected-slave和promoted-slave，它告诉你选出了哪个从节点作为新主。最后一行switch-master表示整个故障转移完成，主节点已经切换为新的地址。

此时检查新主节点的状态：

redis-cli -h 192.168.1.11 -a your_redis_password info replication

会看到role:master，说明节点B已经从从节点晋升为主节点。

再检查其他从节点：

redis-cli -h 192.168.1.12 -a your_redis_password info replication

预期看到master_host:192.168.1.11，说明节点C已经自动将主库切换到新主。

这时候把旧主节点拉起来，观察它会不会自动变成新主节点的从节点：

# 在节点A上启动 Redis /usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf

启动后，自动收敛的魔法就出现了——因为哨兵已经把旧主的配置改写，它会自动通过REPLICAOF连接到新主节点，成为新主节点的从节点。验证方式：

redis-cli -a your_redis_password info replication

输出中role:slave，master_host:192.168.1.11，说明旧的节点A已自动降级为从节点。

4. 生产环境的关键配置与踩坑汇总

能走到这一步，你已经把主从+哨兵的核心链路打通了。但这只是"能跑"，离"稳定跑"还有一段距离。分享一些我用真金白银踩出来的坑。

4.1 脑裂问题与min-slaves配置

脑裂问题（Split Brain）是主从+哨兵架构里最高频的风险。场景还原一下：主节点所在的服务器因为网络分区，与其他节点暂时不可达，但Redis进程还在运行。哨兵集群判断主节点客观下线，把从节点提升为新主。

原本的主节点在隔离区里并没有意识到自己已经失势，还在继续接收写入，导致它在恢复后和新主节点数据不一致。如果业务在这段时间内持续写入旧主节点，这部分数据就会丢失，因为哨兵会将旧主降级为从节点，从新主那里重新同步，旧主上多出来的数据会被清空。

有没有办法尽量降低这种损失？有。Redis提供了min-slaves-to-write和min-slaves-max-lag两个参数：

# 主节点上，至少需要1个健康的从节点才允许写 min-replicas-to-write 1 # 从节点数据延迟最多不超过10秒 min-replicas-max-lag 10

这两个参数组合起来的意思是：如果主节点发现自己当前没有在线的从节点，或者所有从节点的数据延迟都超过了10秒，就拒绝接收写请求，返回错误。这样在脑裂发生的短时间内，即使旧主还能连接，写入也会被拒，数据丢失范围大幅缩小。

代价是可用性下降：如果从节点真的全部不可达，主节点也会拒绝写入。我个人的建议是，在能容忍的情况下开启这个保护，数据安全优先。

4.2 哨兵配置的常见错误与规避

错误一：quorum设置过大或过小

quorum设置为3，但总共只有2个哨兵，故障转移永远不会发生，客观下线条件永远不满足。quorum设置为1，任何一个哨兵误判都会触发主从切换，极易造成频繁切换。

错误二：哨兵配置里主节点地址写错

尤其是从节点上部署的哨兵，如果sentinel monitor写的是从节点的地址而不是主节点的地址，哨兵会把这个从节点当作主节点监控，故障转移逻辑完全不生效。这个是新手最容易踩的坑。

错误三：三个哨兵配置的mymaster名字不一致

每个哨兵文件里的sentinel monitor mymaster，名字必须完全一致，否则它们监控的不是同一个主节点组，哨兵之间无法协同工作。

4.3 Redis 6.x 密码认证的几个坑

在Redis 6.0之前，只有一个requirepass配置，主从之间靠masterauth进行认证。Redis 6.0开始引入了ACL用户体系，如果你用了ACL用户而不是默认的default用户，需要注意：

从节点的masterauth要填正确用户对应的密码，而不是简单的requirepass。比如定义了一个专门用于复制的用户，密码是复制专用密码，从节点的masterauth就要填这个密码。哨兵的sentinel auth-pass也要对应修改。

另外，如果主节点和从节点的密码不相同，比如从节点单独设置了不同的requirepass，哨兵在监控从节点的时候会认证失败，无法正常获取从节点的状态。生产环境建议所有Redis实例使用统一的认证密码，少一个变量就少一个坑。

4.4 监控告警与日常巡检清单

高可用不代表不需要监控，哨兵本身也有挂掉的可能。我推荐的日常巡检项整理如下：

重点说下数据延迟的监控。虽然主从复制是异步的，正常情况下主从延迟非常低（毫秒级），但一旦网络出问题或者从节点负载过高，数据延迟可能飙升。建议定时脚本定期对比主从节点的master_repl_offset和slave_repl_offset，差值的绝对值就是当前的复制积压量。

4.5 主从同步延迟的持久优化方案

如果你发现主从同步延迟始终无法收敛，除了检查网络和repl-backlog-size，还需要关注几个方向：

第一是主节点的写负载。如果主节点写QPS极高，每个写命令都要同步给所有从节点，网络带宽会成为瓶颈。适当的做法是增加从节点数量的同时，评估主节点的网卡带宽和CPU处理能力。一般建议单主节点拖2到3个从节点比较合理，如果读压力特别大，可以使用多级从节点结构。

第二是大Value操作。一个几十MB的Value如果频繁更新，全量复制和增量同步的成本都极高。这种情况建议在业务层面拆分数据结构，或者使用Hash等内存友好的结构降低单Key的体积。

第三是主从部署在不同机房时，机房之间专线质量差会导致同步延迟。生产环境我一般建议主从至少在同一内网，跨地域场景优先考虑多主多活方案而不是主从复制。

5. 最后还是分享点实在的经验

搭建Redis主从+哨兵这套方案，本身并不复杂，但如果只是照着文档把配置文件填一遍，很容易在关键时刻掉链子。我见过多次线上事故，都是因为某个细节没有注意到，比如quorum设置有误、哨兵配置文件里的主节点地址写错了、或者没有开启min-replicas保护就发生了脑裂。

根据我的经验，每次部署完成后一定要做的三件事：第一，做一次完整的主节点宕机演练，看哨兵是否能在预期时间内完成切换；第二，检查旧主节点恢复后是否自动降级为从节点；第三，用脚本监控复制偏移量，确保主从数据没有延迟越积越多。这三步走完，这套高可用方案才算是真正落地了。等业务量涨到数据必须分片的时候，再考虑迁移到Cluster模式也不迟。