去年Q3，某跨境电商大促期间，Redis宕机14分钟，订单流失率飙到23%。根因很荒谬：EKS上跑的单节点Redis，所在可用区（AZ）网络抖动，整个购物车系统跟着陪葬。
这不是个案。AWS官方文档从没告诉你——用默认配置搭的Redis，本质上是个"玻璃大炮"。
单节点Redis的死亡螺旋
Redis在Kubernetes里的部署，很多人图省事：一个StatefulSet，一个PVC，完事。这种配置在EKS上跑起来很快，但容错能力是零。
故障链路像多米诺骨牌：节点挂了→Pod漂不走→存储卷锁死→Redis失联→依赖它的服务全崩。
更隐蔽的是AZ级故障。K8s的持久卷（Persistent Volume）默认绑定单个可用区，一旦整个AZ出问题，Pod想漂到其他区？门都没有。存储卷和节点是焊死的。
有人试过用Bitnami的Redis Helm chart搭主从+Sentinel，结果发现坑更深——如果你用了RedisJSON、RediSearch这些自定义模块，Sentinel的故障切换会直接失效。HA和高级功能二选一，这题没法做。
Dragonfly号称兼容Redis且自带多线程，但模块生态还没对齐，迁移成本不低。
多AZ部署的硬约束
真想扛住AZ级故障，得同时解三个方程：消除单点、保住模块功能、保持K8s原生可移植。
存储层必须跨AZ。AWS的EBS卷做不到，得换方案——要么用EFS（性能牺牲大），要么上多副本的存储类（如TopoLVM跨AZ调度），或者干脆把Redis数据层和ElastiCache解耦。
但ElastiCache又锁死AWS，混合云场景下直接出局。
自管Redis的替代路径是强制多副本：至少3个节点跨3个AZ，Sentinel或Redis Cluster做故障探测。副本数不是越多越好——网络分区时，过半机制会卡住写操作，得在CAP里做取舍。
一个被忽略的细节：K8s的PodDisruptionBudget。节点维护时，如果没设置PDB，K8s可能直接把Redis主节点干掉换新，触发不必要的切换。这个配置很多人漏掉。
模块兼容性这个暗雷
RedisStack把JSON、搜索、时序数据打包进一个镜像，用起来爽，运维时哭。
Sentinel的故障切换逻辑基于INFO命令解析主从状态，但模块加载后的Redis实例，某些版本的INFO输出格式会变。Sentinel误判节点状态，切主失败，整个HA机制形同虚设。
社区里有团队试过自己改Sentinel的解析逻辑，维护成本爆炸。也有人用Redis Cluster替代，但Cluster的槽迁移和模块的内存结构偶尔冲突，大key场景下会触发不可预期的OOM。
目前没完美的自研方案，只有权衡后的妥协。
务实的做法是：把模块功能拆出去。搜索用专门的搜索引擎，JSON结构化数据考虑持久化KV或文档数据库，别让Redis背所有锅。
云厂商不会替你兜底
EKS的SLA只保控制平面，不保你跑的Pod。Redis挂了，AWS工单回复通常是："您的应用架构建议参考Well-Architected Framework。"
翻译：自己想办法。
有些团队试过用AWS MemoryDB——全托管、多AZ、自动故障切换。但价格是自管Redis的3-5倍，且同样不支持自定义模块。成本敏感的业务根本用不起。
另一个选项是跨云部署Redis Cluster，节点分布在AWS、GCP、Azure。理论上行得通，实际网络延迟和脑裂处理能把运维逼疯。除非有强合规要求，否则不建议。
最务实的路线还是扎根K8s生态：用Operator（如Redis Operator或Opstree的解决方案）自动化主从切换，配合Velero做跨AZ备份，再搭一套 Prometheus+Alertmanager 的监控兜底。
这套组合拳不性感，但能活过下一个AZ故障。
那位跨境电商的SRE后来复盘，在事故报告里写了句话：「我们以为K8s会自动治愈一切，直到发现它连一个AZ都跨不过去。」
你的Redis现在几个副本？PVC绑在哪个AZ？
热门跟贴