“Redis又崩了？
”
凌晨三点，群里一句哀嚎，比闹钟还提神。
别急着骂运维，八成是架构没选对。
单机当生产用，主从没配哨兵，集群却拿来做缓存——踩坑姿势年年翻新，Redis背锅侠永远在线。
先拆个最痛的：为什么同一条set命令，本地毫秒级，线上能卡到秒？
答案藏在事件循环里。
Redis表面单线程，其实6.0之后偷偷开了I/O线程，读和写外包出去，主线程只负责“算账”。
如果客户端一次性灌几千条大key，I/O线程瞬间塞满，主线程排队等解析，延迟直接起飞。
解决也简单：
- 把大key砍成小key，别让单条value超过1 MB；
- 客户端加pipeline，一次打包百条命令，减少往返；
-监控里把“instantaneous_input_kbps”拉出来，飙红就报警，比事后翻slowlog痛快。
再说高可用。
很多团队把哨兵当摆设，三个哨兵节点全扔同一台宿主机，宿主机一挂，哨兵集体失联，主从切换失败，业务雪崩。
真想救命，哨兵至少跨机架，最好跨可用区。
云厂商给的托管版Redis直接做多活，跨城延迟也能压到5ms以内，省得自己折腾。
持久化二选一？
成年人全都要。
RDB恢复快，但丢数据；AOF不丢，但文件膨胀。4.0之后的混合持久化，先RDB打底，再追加增量AOF，重启时先加载RDB，再重放AOF尾巴，既快又稳。
唯一注意：AOF重写别放在高峰期，IO打满照样卡哭。
内存碎片常被人忽略。
jemalloc确实比glibc省，但长连接+频繁update，碎片率还是能飙到30%。
线上实测：把maxmemory-policy从volatile-lru改成allkeys-lfu，碎片率直接掉一半，命中率还涨了3%。
原因？
LFU把冷数据踢得更干净，内存池更平整。
模块玩法现在越来越野。
-RedisJSON一把梭，直接把MongoDB的活抢了，嵌套文档查询延迟压到亚毫秒；
-RediSearch做商品搜索，倒排索引放内存，分词+过滤+排序一条龙，秒杀MySQLlike '%关键词%'的噩梦。
唯一门槛：模块版本必须和Redis主版本对齐，升级前先在测试环境跑两周压测，别线上直接梭哈。
云原生时代，Operator成了新玩具。
K8s里一条yaml就能拉起三主三从的集群，节点挂了自动重建，PV跟着走，数据不丢。
但别高兴太早，Operator默认的resource limit只有100 mCPU+128Mi，压测一上QPS直接被打回POD重启。
经验值：给每个Redis节点至少2核4G，limits和requests写一样，避免节点被kubelet OOM kill。
最后留一个私货：
如果业务只是简单缓存，且QPS<1万，真没必要上集群。
一台8核32 G的虚拟机，主从+哨兵，配好监控和告警，足够扛90%场景。
省下的预算，拿去请团队喝奶茶，比折腾分布式快乐多了。
Redis不复杂，复杂的是人总想用它解决所有问题。
选对模式，盯紧指标，少点炫技，多点敬畏，凌晨三点的群才会安静。