-
安全重启Redis集群的正确做法是逐个节点操作，优先处理从节点，严格等待redis-cli--clustercheck返回OK后再进行下一轮，避免脑裂、槽位丢失和连接雪崩。
-
slowlog是Redis唯一实时捕获慢命令的机制，为内存环形缓冲区，仅记录执行耗时超阈值的命令，不包含网络延迟与排队时间；默认阈值10ms，建议调至5ms，slowlog-max-len建议设为1024，并需CONFIGREWRITE持久化。
-
后台线程异步刷新热Key本质是“逻辑过期+守护任务”组合，由应用层实现定期扫描预判并更新热点数据，需嵌逻辑过期时间于value中、合理设扫描频率与范围，并加分布式锁、失败重试及错峰调度。
-
在Redis集群中查某个key的实时内存占用需先定位其所在slot和节点：用CLUSTERKEYSLOT算slot号，CLUSTERSLOTS查对应主节点IP:PORT，再连该节点执行MEMORYUSAGE；因官方redis-cli--cluster不支持透传该命令，且结果为估算值，需注意偏差与重试机制。
-
典型现象是Redis从节点反复断连，日志出现“Clientclosedconnectionduetooutputbufferlimit”，INFOreplication中状态在connect→sync→disconnected循环；主节点因输出缓冲区超限（默认slave256MB/64MB/60s）主动断开连接。
-
Redis禁止BGSAVE与BGREWRITEAOF并发执行，是为避免双子进程争抢CPU、I/O、COW内存页及fsync队列；前者返回错误，后者被排队；no-appendfsync-on-rewriteyes可缓解AOF重写时主进程fsync阻塞，但对BGSAVE无效。
-
根本原因是Redis集群要求多键操作的key必须位于同一slot，而HashTag（如{user:1}:profile）通过仅哈希花括号内内容实现强制同槽，但需命令本身支持多key且全链路保留括号语义。
-
用iptables模拟Redis哨兵网络分区需双向封禁节点间通信（INPUT+OUTPUT），匹配6379/26379端口，确保Quorum计算失效；恢复时须精准删除规则而非清空链，避免锁死服务器。
-
allkeys-random策略在内存超限时随机删除任意key，适合一致性要求低的缓存场景；需先配置maxmemory，且不区分key是否设过期时间。
-
sentinelmonitor三要素（master-name、IP、port）必须准确，缺一不可，否则哨兵无法发现主从拓扑；quorum是触发投票的最小同意数，非哨兵总数；密码需三端一致（requirepass/masterauth/auth-pass），ACL还需配置masteruser；down-after-milliseconds宜设3000–5000ms防误判；启动前须确保主从就绪，否则从节点被误标sdown。
-
reshard搬的是Slot而非Key，先重分配16384个Slot，再由集群自动触发Key迁移；需待“Allkeystransferred”提示才完成，且新节点须完成注册、握手、身份确认三步并满足网络与配置要求。
-
必须显式配置client-output-buffer-limit，否则普通客户端无输出缓冲区上限，易致内存耗尽；需为normal、pubsub等类型分别设置hard/soft限制，尤其pubsub缓冲区最易失控。
-
Redis主从切换后连接池未刷新导致请求超时或Connectionrefused，因Jedis/Lettuce默认不自动感知拓扑变更；需手动重建连接池或使用Lettuce6.0+内置重连机制。
-
必须配合日期动态生成key，因Bitmap无时间维度，共用key会丢失日期信息且导致单key膨胀、RDB/AOF暴增、主从延迟；用户ID须映射为非负整数offset，避免直接强转；BITCOUNT偏高多因key未清理或offset错位；5000万DAU下Bitmap体积约6.25MB，但需防ID稀疏浪费内存。
-
Redis布隆过滤器不支持动态扩容，BF.RESERVE设定的capacity和error_rate不可修改；扩容需手动迁移数据并切换key，参数选错易致内存激增或OOM。
