-
不会阻塞。RDB持久化由fork()子进程执行，主线程继续处理请求；依赖Linux内核写时复制（COW）机制，fork后父子进程共享物理内存页，仅在修改时才复制对应页，保证子进程读取fork时刻快照，但高写入会加剧COW开销。
-
Redis集群不自动随机化过期时间，需业务层实现；限流须在应用层或网关层统一控制；热点key需加扰动后缀分散分片；三者叠加（集群+随机过期+限流）且随机范围≥±5%才有效防雪崩。
-
用iptables模拟Redis哨兵网络分区需双向封禁节点间通信（INPUT+OUTPUT），匹配6379/26379端口，确保Quorum计算失效；恢复时须精准删除规则而非清空链，避免锁死服务器。
-
allkeys-random策略在内存超限时随机删除任意key，适合一致性要求低的缓存场景；需先配置maxmemory，且不区分key是否设过期时间。
-
应使用LettuceConnectionFactory替代JedisConnectionFactory，因其原生支持Netty和响应式API；必须配合ReactiveRedisTemplate，并正确配置StringRedisSerializer等序列化器，避免阻塞调用与序列化不匹配问题。
-
+sdown表示单个哨兵认定主节点失联，+odown才是触发故障转移的共识临界点；两者时间差暴露网络或配置问题，+odown后还需经选举、选从库、提升等步骤才能完成切换。
-
sentinelmonitor三要素（master-name、IP、port）必须准确，缺一不可，否则哨兵无法发现主从拓扑；quorum是触发投票的最小同意数，非哨兵总数；密码需三端一致（requirepass/masterauth/auth-pass），ACL还需配置masteruser；down-after-milliseconds宜设3000–5000ms防误判；启动前须确保主从就绪，否则从节点被误标sdown。
-
Redis从库默认只读，slave-read-onlyyes是防意外写入的保险栓；设为no后从库可写但导致主从数据不一致，因写命令不回传主库且故障转移会扩散脏数据。
-
Redis6+的io-threads应设为2~8，不超过磁盘队列深度的2倍，且必须保持io-threads-do-readsno；它仅加速写入内核页缓存，不加速fsync，设得过多反而加剧IOWAIT和延迟。
-
主节点应禁用RDB、仅启用AOF（appendonlyyes）并设appendfsync为everysec；AOF重写需协同配置auto-aof-rewrite-percentage（如70）、auto-aof-rewrite-min-size（如64mb）及no-appendfsync-on-rewriteyes；RDB快照宜按业务峰谷调整save策略，避免高频fork。
-
Redis4.0起，24位lru字段在LFU模式下拆为高16位ldt（分钟级时间戳）和低8位logc（对数计数器），ldt=(time_t/60)&0xFFFF，logc初始为5并用概率递增算法更新。
-
集群模式下slave-read-onlyyes无效，因集群协议绕过主从配置；必须用readonly命令开启连接级只读，使从节点响应本主槽读请求。
-
reshard搬的是Slot而非Key，先重分配16384个Slot，再由集群自动触发Key迁移；需待“Allkeystransferred”提示才完成，且新节点须完成注册、握手、身份确认三步并满足网络与配置要求。
-
必须显式配置client-output-buffer-limit，否则普通客户端无输出缓冲区上限，易致内存耗尽；需为normal、pubsub等类型分别设置hard/soft限制，尤其pubsub缓冲区最易失控。
-
要定位被淘汰的key，需监控evicted_keys增量、expired_keys飙升情况，并结合Redis7.0+的MEMORYUSAGE与OBJECTFREQ抽样分析；allkeys-lru不安全，应优先用volatile-lru/lfu；LFU更耗CPU因频次衰减更新；验证key是否频繁淘汰可用PFADD+PFCOUNT埋点统计。
