Redis内存淘汰只在主节点生效，副本仅同步淘汰动作；验证需查主节点maxmemory非零、maxmemory-policy非noeviction，且evicted_keys持续增长。
只读副本默认不执行淘汰操作
Redis 的内存淘汰（eviction）只发生在**主节点（master）**，副本（replica）本身不主动触发淘汰逻辑——它只是同步主节点的写命令和删除操作。所以你在只读副本上执行 CONFIG GET maxmemory-policy 看到的是配置值，但该策略**不会实际生效**。即使副本 used_memory 超过 maxmemory，它也不会拒绝写入（因为副本默认 read_only yes），更不会主动删 key。
验证必须回到主节点查实时行为
想确认淘汰策略是否真正起作用，不能只看副本的配置输出。你需要在主节点上做三件事：
- 运行
CONFIG GET maxmemory：确保返回非零值（如"2gb"），否则淘汰机制压根不启动 - 运行
CONFIG GET maxmemory-policy：确认策略不是noeviction（除非你明确要拒绝写入） - 观察
INFO stats中的evicted_keys计数器：该值持续增长，才是淘汰真正发生的直接证据
注意：evicted_keys 是累计值，重启后归零；如果它长期为 0，说明要么没到阈值，要么策略未启用，要么所有 key 都没被选中（比如用 volatile-lru 但大部分 key 没设 TTL）。
副本上能查什么？仅限状态同步验证
虽然副本不淘汰，但它会同步主节点的淘汰动作。你可以间接验证同步是否正常：
- 在主节点执行
redis-cli --bigkeys找出一个大 key，手动DEL它，再立刻在副本上EXISTS检查，确认是否同步删除 - 对比主从的
INFO memory | grep used_memory：正常情况下，副本used_memory应略低于主节点（因复制缓冲区开销不同），但趋势应一致；若副本内存持续上涨而主节点稳定，可能是复制延迟或副本配置了额外写操作（如replica-read-only no） - 检查副本的
INFO replication中master_repl_offset和slave_repl_offset是否接近，差值过大说明同步滞后，此时看到的内存状态已失真
云托管 Redis 的特殊限制
阿里云 Tair、腾讯云 CRS 等托管服务通常禁用 CONFIG 命令，且副本节点可能完全屏蔽该指令。此时：
- 不要依赖副本上的
CONFIG GET结果，它可能返回空或报错 - 去控制台「参数设置」页查主节点策略，或用
redis-cli -a $PASS INFO | grep maxmemory-policy（部分兼容版本会把策略塞进INFO输出） - 集群模式下，每个分片独立配置，必须逐个
redis-cli -c -p PORT连接主 shard 查，副本 shard 不代表整体策略
真正关键的不是“副本有没有配置”，而是“主节点有没有在淘汰、淘汰是否被正确同步”——后者靠 evicted_keys 和复制偏移量比对来判断，比单纯看配置可靠得多。
