从节点cpu飙升最常见原因是隐式反复执行bgsave：主从同步中从节点被误配save策略或云平台全局下发持久化配置，导致其频繁fork落盘；需查info persistence的rdb_bgsave_in_progress及latest_fork_usec，并禁用从节点所有save规则与aof。
从节点CPU突然飙升，先查BGSAVE是否在后台狂刷
Redis从节点负载反超主节点，最常见却最容易被忽略的原因是：从节点在反复执行BGSAVE——不是你主动触发的，而是主从同步流程中隐式触发的。主节点只在配置了save规则或手动调用时才落盘；但从节点只要开启slave-serve-stale-data no（默认yes）且加载RDB期间被要求提供服务，就可能被迫在首次同步后立即再做一次BGSAVE；更隐蔽的是，某些云厂商控制台“启用持久化”开关会全局下发save配置到所有节点，包括从节点。
验证方式很简单：INFO persistence里看rdb_bgsave_in_progress是否为1，再配合INFO stats里的latest_fork_usec——如果这个值频繁跳升（比如每分钟都出现几万微秒），说明fork开销正在持续吞噬CPU。
从节点RDB加载完成后的“二次落盘”陷阱
很多团队以为从节点只负责读、不落盘，但实际中存在两类强制落盘场景：
-
slave-read-only no被误设时，从节点接受写入，触发自身save策略 - 使用Redis 6.0+且开启
replica-announce-ip后，部分集群拓扑探测逻辑会触发CONFIG REWRITE，间接导致BGSAVE
重点检查：CONFIG GET save和CONFIG GET slave-read-only。如果返回类似1) "save" 2) "3600 1"，说明从节点被配了每小时保存1次，而它又没主节点那么强的IO能力，BGSAVE过程就会卡住主线程、拉高系统负载。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
为什么INFO replication看不出问题？
INFO replication只告诉你主从连接状态、偏移量、角色，完全不反映从节点自身的持久化行为。一个从节点可以master_link_status:up且slave_repl_offset追得很紧，同时在后台默默每5分钟fork一次做RDB——这正是监控盲区。
真正该盯的指标是：
-
redis_rdb_changes_since_last_save（Prometheus exporter暴露的指标，非原生命令） -
INFO commandstats里cmdstat_save和cmdstat_bgsave的calls计数是否异常增长 - 系统层用
pidstat -p $(pgrep redis-server) 1观察%wait和%cpu抖动是否与redis-cli info | grep bgsave输出时间吻合
临时止血和长期规避方案
从节点不是备份服务器，不该承担落盘责任。根治思路就是切断它的持久化冲动：
- 在从节点配置中显式禁用所有
save规则：save ""（空字符串清空所有规则） - 确认
stop-writes-on-bgsave-error no已设，避免因磁盘满导致连锁故障 - 如使用AOF，必须关掉：
appendonly no——从节点AOF重放本身就会吃CPU，再加AOF rewrite等于双杀 - 云服务用户注意：阿里云/腾讯云控制台的“持久化开关”默认作用于全部节点，需单独进从节点实例详情页关闭
做完这些，再跑redis-cli -h <slave_ip> -p <port> CONFIG REWRITE</port></slave_ip>让配置落地。别指望重启生效——有些版本的Redis在CONFIG SET后不持久化，改完不REWRITE，下次滚动更新就回去了。
