从单机到集群，我踩了Redis这9个生产事故——附完整排查手册

单机Redis扛到什么时候会撑不住？根据经验，当QPS超过8万、数据量超过25GB、或者业务要求99.99%可用性的时候，单机Redis基本就到头了。内存不够可以加内存，CPU不够可以升配，但单点故障这个问题，靠堆硬件解决不了。所以你迟早要上Redis集群。问题在于，Redis集群不是简单地把几台Redis凑在一起就完事了。它有自己的数据分片逻辑、节点通信协议、故障检测机制和数据迁移流程，每一层都可能出问题。这些问题在测试环境很难暴露——往往是流量上来之后、或者节点挂掉的瞬间才会炸出来。更要命的是，这些问题互相关联：大Key会导致迁移卡顿，迁移卡顿会引发重定向风暴，重定向风暴又会拖垮客户端连接池，像推倒多米诺骨牌一样连锁反应。这篇文章整理了Redis集群在生产环境中最容易踩的9个坑。每个坑都包含问题现象、根因分析、排查思路和解决方案，文末附了一份完整的排查手册速查表。如果你是C++后端工程师，正在用或者准备用Redis集群，建议收藏这份排查手册。先花5分钟搞清楚Redis集群的架构在讲具体事故之前，需要把Redis集群的核心架构快速过一遍。后面每个事故的根因分析都会用到这些概念，如果你对Redis集群已经比较熟悉可以直接跳到事故一。16384个Hash Slot：数据分片的基础Redis集群把整个键空间切成16384个槽位（Hash Slot）。每个key通过CRC16算法算出一个哈希值，然后对16384取模，得到这个key属于哪个槽位。公式就一行：slot = CRC16(key) % 16384