为什么值得列成清单
这些误区的共同点是上线时都不炸，流量涨上来才炸。把它们整理成清单，用在开发评审、上线检查和事故复盘里，比每次现场救火划算得多。清单覆盖四个方向：使用定位（是否当数据库）、容量治理（TTL 与大 key）、性能红线（KEYS 与连接）、版本与集群约束。
高频误区清单
- 当主存储用：持久化存在丢数窗口，权威数据必须落库
- 缓存键没有 TTL：堆满后触发淘汰，热数据被冷数据挤掉
- 大 key：百万元素的集合查一次卡一次，治理靠拆分与异步删除
- 热 key：单分片 CPU 被打满，靠本地缓存、多副本或键打散
- KEYS 扫全库：生产环境禁用，改用 SCAN 渐进遍历
- 连接管理混乱：每请求新建连接或连接池上限过大，打满 maxclients
- 忽略版本差异：LMPOP、ZINTERCARD、FUNCTION 等命令 7.0 才有
- 缺集群意识：多键不在同槽会报 CROSSSLOT，键设计要带 hash tag
上线前体检命令
上线前体检命令
redis-cli INFO clients | grep connected_clients
redis-cli INFO memory | grep -E "used_memory_human|maxmemory_human"
redis-cli INFO stats | grep -E "evicted_keys|expired_keys"
redis-cli --bigkeys -i 0.1 # 低峰或副本执行，-i 用于限速
redis-cli --hotkeys # 需要 LFU 淘汰策略才有效
redis-cli SLOWLOG GET 10
redis-cli CLUSTER INFO | grep state误区与正确做法
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 当数据库用 | 持久化窗口内丢数据不可恢复 | 权威数据落库，缓存只做加速 |
| 无 TTL | 内存被冷数据占满，热数据被淘汰 | 缓存键必须有 TTL 或显式豁免 |
| 大 key | 单次操作阻塞单线程 | 拆分结构，删除用 UNLINK 异步处理 |
| 热 key | 单分片或单节点压力集中 | 多级缓存、读写分离、键打散 |
| KEYS 模式匹配 | 遍历全库阻塞数秒到数十秒 | 用 SCAN 游标渐进遍历 |
--bigkeys 与 --hotkeys 都会遍历键空间：在主库高峰执行等于自己制造故障，安排在低峰或从库上执行。
容量估算不要用「平均大小乘键数」：过期键、内存碎片、复制缓冲区、AOF 缓冲区都会吃内存，实际占用通常明显高于估算值。
上线前做一次「命令可用性核对」：把代码里用到的 Redis 命令在目标版本上全部跑一遍，避免本地老版本测试通过、线上报 unknown command。