-
Redis从库默认只读，slave-read-onlyyes是防意外写入的保险栓；设为no后从库可写但导致主从数据不一致，因写命令不回传主库且故障转移会扩散脏数据。
-
主节点配置requirepass后从节点同步失败，因从节点未配置masterauth导致认证失败；需在从节点配置文件中设置masterauth或运行时CONFIGSET，并配合ACL权限、bind限制与防火墙加固。
-
Redis6.2+需用--cluster参数运行redis-benchmark，否则MOVED/ASK重定向导致QPS归零；低版本需手动固定槽位或升级。
-
云盘IOPS不足会导致bgsave失败或超时，因RDB全量写入触发IO拥塞，表现为“Nospaceleftondevice”错误（实际空间充足）；需升级ESSDPL1及以上云盘、确认dir指向高IOPS数据盘、启用混合持久化并禁用save命令。
-
RedisRDB快照生成失败时bgsave返回ERR，主因是fork()系统调用失败，典型表现为日志中出现“Failedtofork()forRDB:Cannotallocatememory”或“Resourcetemporarilyunavailable”，根本原因在于Linux的vm.overcommit_memory设置不当（默认0易拒绝fork）、内存压力过大、ulimit-u或pid_max耗尽，或cgroup内存限制过严；应将vm.overcommit_memory设为1并检查cgroup限制
-
redis.call()比redis.pcall()更易触发OOM，因其失败即终止，而pcall()返回的错误表常驻Lua栈且累积不释放，RedisLua引擎仅在脚本退出时批量GC。
-
不会阻塞。RDB持久化由fork()子进程执行，主线程继续处理请求；依赖Linux内核写时复制（COW）机制，fork后父子进程共享物理内存页，仅在修改时才复制对应页，保证子进程读取fork时刻快照，但高写入会加剧COW开销。
-
布隆过滤器是解决缓存穿透最可控的手段，需部署在Redis之前拦截非法key；它不支持删除、存在误判率，须按真实数据量预估容量，并配合参数校验与限流使用。
-
Redis集群连接失败需先确认服务端启用cluster-enabledyes且至少3个主节点；客户端必须用redis-cli-c或集群驱动，否则报MOVED错误；KEYS*等跨slot命令不支持，SCAN需遍历各节点执行。
-
Redis集群默认不支持读写分离，所有请求均被重定向至主节点，从节点仅用于故障转移；如需读写分离，须弃用集群客户端，改用普通主从客户端自行路由。
-
不能直接用RedisPub/Sub做缓存一致性保障，因其不保证消息可达，订阅者离线时消息丢失，无重试、ACK或持久化机制；必须结合RedisStream落地事件+数据库状态校验实现最终一致。
-
RedisPub/Sub无法缓冲积压消息，因其纯内存广播机制不重试、不排队，消息直接丢弃；应改用List+BRPOP实现带缓冲队列，并由业务明确管理消息生命周期。
-
是，HLL适合统计日活UV，但需接受约0.81%误差且不支持成员查询与精确交集；按日期分key（如uv:20240520）、设过期、统一用户标识方可稳健使用。
-
AOF重写阻塞主线程的根本原因是fork()系统调用引发的页表复制与copy-on-write冲突；高频key修改导致大量脏页拷贝，使fork耗时飙升。
-
Pub/Sub频道命名必须带租户前缀，采用三段式结构{租户标识}:{业务域}:{实体ID}，禁用裸频道和通配符泛订阅；ACL需按前缀精确控制，显式授权+subscribe/+publish；TLS与消息体加密必须同时启用；Pub/Sub不可替代可靠队列，应改用Stream或List。
