-
Redis客户端重连易打挂新主库，因默认“失败即重试”导致连接风暴；需配置指数退避+随机抖动（如Lettuce用ExponentialBackoffRetry.withJitter）、Go端自定义DialContext重试逻辑，并控制初始延迟50–100ms、最大延迟≤3s、重试8–12次。223 收藏 -
分片后每个Redis节点必须独立配置持久化，RDB需统一save规则且隔离磁盘路径，AOF应全节点开启并设appendfsynceverysec，避免部分节点未持久化导致数据丢失。158 收藏 -
ZUNIONSTORE合并多个ZSet时相同member的score默认相加；海量数据下会严重阻塞Redis主线程；需注意目标key编码、memberID统一及分批合并等实践要点。402 收藏 -
直接用LPOP或LRANGE处理大列表会阻塞，因其时间复杂度为O(N)，在单线程Redis中长时间占用CPU，导致后续请求排队、超时及连接池耗尽。393 收藏 -
Redis内存爆满主因是业务接口批量生成无TTL垃圾Key，需在防火墙层限流新建连接并绑定127.0.0.1监听，禁用公网暴露与弱密码。112 收藏 -
应使用Redis的Hash或ZSet维护用户会话映射，新登录时先获取并删除旧会话缓存及黑名单，配合事务或Lua脚本保证并发安全，而非仅依赖EXPIRE。491 收藏 -
volatile-ttl策略仅在内存达限且有写入时触发，随机采样已设TTL的key并淘汰其中剩余过期时间最短者，并非主动或精准清理“马上过期”的key。441 收藏 -
Redis发布订阅怕大Key是因为PUBLISH不校验消息大小，大Payload会阻塞单线程主线程，导致延迟飙升、内存积压；应用层需在序列化后截断或拒绝超限消息（如>100KB），订阅端须预检长度并禁用自动解码，大Payload场景应改用SET+key事件、DB查询或Kafka等替代方案。491 收藏 -
Redis集群执行Lua脚本失败大概率因KEYS未落在同一slot，必须用{}哈希标签确保所有KEYS经CRC16计算后归属相同slot，否则直接报CROSSSLOT错误，EVALSHA同理受限，脚本无法补救key设计缺陷。120 收藏 -
Redis哨兵模式不支持自动伸缩，其核心能力仅限于监控存活、触发故障转移和提供主节点地址；它不参与节点增删、数据分片或路由更新。339 收藏 -
BloomFilter不能单独用于消息去重，因其存在误判率；必须配合Redis的SET或ZSET做最终校验：SET适用于简单幂等场景，ZSET支持滑动窗口限频，典型流程为BloomFilter预筛→Redis精确判定→三重写入。277 收藏 -
根本原因是repl-backlog-size过小或网络闪断超时，导致从节点重连时偏移量超出缓冲区范围而无法增量同步，被迫触发全量同步。409 收藏 -
ZREVRANGEBYSCORE不适用于超时任务检测，因其按score降序返回，而超时检测需升序查找score≤当前时间戳的任务；正确做法是用ZRANGEBYSCOREtasks-inf[current_timestamp]配合Lua原子执行扫描与删除，并确保score为高精度到期时间戳以避免排序混乱和堆积性能问题。370 收藏 -
AOF本质是只追加不修改的文本日志，通过重放命令恢复数据；appendfsync决定落盘策略，everysec为生产默认；SELECT因影响命令作用域被记录；BGREWRITEAOF基于内存快照重生成最小日志；no-appendfsync-on-rewrite可缓解重写时I/O竞争。177 收藏 -
AOF文件无法直接看出某条key被谁改过，因其仅记录命令文本，不包含时间戳、客户端ID或用户标识；需通过业务层打标或Proxy日志实现审计溯源。398 收藏
