从节点cpu飙升与sinter/sunion无关，因其不执行客户端读命令；真正原因是主节点推送的复制流中大量集合写指令（如sadd、sinterstore）需从节点逐条解析与执行，尤其大集合重建、intset扩容及smove高频调用会显著增加cpu开销。
为什么从节点CPU飙升可能和SINTER/SUNION无关
Redis 主从复制是异步的，从节点不执行客户端发来的 SINTER、SUNION 等读命令——这些命令只在主节点执行并返回结果。从节点的 CPU 消耗，几乎不会来自你主动发起的集合运算请求。
真正会让从节点 CPU 上升的，是主节点推送的 replication stream（复制流）解析与写入动作。当主节点高频执行大量 Set 写操作（如 SADD、SREM、SINTERSTORE），尤其涉及大集合时，产生的 AOF rewrite 或 RDB 生成压力会间接传导到从节点：它要持续 apply 大量集合变更指令，而每个 SADD 成员都是一条独立协议帧，解析+哈希插入开销累加起来很可观。
-
SINTERSTORE在主上执行后，会把整个结果集以多条SADD命令形式重放给从节点，不是“传一个集合”，而是传 N 条指令 - 如果目标 key 是
intset编码但频繁扩容（比如从 1000 个 int 扩到 10 万），从节点在重建 intset 时会有额外内存拷贝成本 - 从节点启用
replica-serve-stale-data no时，若主从断连后重同步，全量 sync 阶段会加载 RDB，此时 CPU 尖峰和内存带宽占用都会明显升高
怎么确认是不是集合类操作拖垮了从节点
别只看 top 或 htop，先查 Redis 自身指标：
- 运行
INFO replication，重点看master_last_io_seconds_ago是否长期 > 5，说明复制延迟大，可能是网络或从节点处理不过来 - 运行
INFO commandstats，找cmdstat_sadd、cmdstat_sinterstore的calls和usec_per_call，注意这是主节点数据；从节点上这些字段值通常极低甚至为 0 - 用
redis-cli --stat观察从节点每秒处理的命令数是否突降，同时redis-cli -r 1 -i 1 INFO | grep instantaneous_ops_per_sec看实时 OPS 波动
如果发现从节点 used_cpu_sys 持续高于 2.0（单位：秒/秒），且 mem_fragmentation_ratio > 1.5，大概率是内存分配器在高压下频繁调用 mmap/brk，和集合大小无直接关系，但大 Set 写入会加剧碎片。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
哪些集合操作会让从节点更吃力
不是所有 Set 命令对从节点影响一样。以下三类会在从节点引发更高 CPU 占用：
-
SINTERSTORE dest key1 key2 key3：dest 若为空，从节点需逐条重放所有成员写入；若 dest 已存在且是大集合，SINTERSTORE会先清空再写，触发两次遍历 -
SMOVE高频调用：每次都是「删 + 增」两步，复制流里变成两条命令，解析开销翻倍 - 用
SSCAN+ 客户端聚合模拟交并差：虽然避开了主节点阻塞，但扫描结果要经网络传到客户端，再由客户端计算后写回 Redis —— 这些写回的SADD全部落在从节点 replay 队列里
特别注意：SUNION 本身不落盘、不复制，但它常被误用于构造中间结果再 SADD 到新 key，这种组合才是真凶。
压测时怎么隔离从节点集合负载
想真实评估从节点扛不扛得住，不能只在主上跑 SINTER 然后看从节点 CPU —— 那测的是网络和解析，不是集合运算本身。正确做法是模拟复制流压力：
- 用
redis-cli --rdb /dev/null抓取主节点当前 RDB 快照，用redis-check-rdb --deep看其中最大 Set 的元素数量和编码类型 - 写一个脚本，生成等效的
SADD序列（例如对 50 万个 ID 的集合，生成 50 万行SADD tag:tech id1），用cat script.txt | redis-cli -h slave-host -p 6379直接喂给从节点 - 观察
used_cpu_sys和evicted_keys是否同步上涨；如果evicted_keys > 0，说明 OOM Killer 或淘汰策略已介入，此时集合数据规模已超出安全水位
真正危险的信号不是 CPU 高，而是 slave_repl_offset 跟不上 master_repl_offset 且差距持续扩大——这意味着从节点正在丢指令，复制链路不可靠，后续任何基于集合的一致性逻辑都可能出错。
