某大厂技术团队曾在凌晨三点被一通电话惊醒：核心Redis集群宕机，所有接口瞬间超时。调查发现，故障原因是一个节点内存被打满。问题不在Redis本身，而在于分布式存储方案没选对。今天聊清楚三件事：三种主流方案各有什么坑，以及你在真实业务中该怎么选。

Redis分布式存储：为什么你的缓存集群总在关键时刻掉链子？

某大厂技术团队曾在凌晨三点被一通电话惊醒：核心Redis集群宕机，所有接口瞬间超时。调查发现，故障原因是一个节点内存被打满——而那台机器上同时跑了17个Redis实例。运维人员苦笑："我们以为分布式很安全，结果17个兄弟一起躺了。"

这不是孤例。我接触过至少五六家公司在"上Redis集群"之后，反而出现了比单机更频繁的故障。问题不在Redis本身，而在于分布式存储方案没选对。

今天聊清楚三件事：三种主流方案各有什么坑，以及你在真实业务中该怎么选。

三条路，各有各的死法

早期团队最喜欢干的事：既然要分片，那我直接在客户端写逻辑，Hash一下key，决定往哪台Redis发请求不就完了？

好处显而易见：没有中间层，零额外延迟，架构看起来也清爽。

代价是：所有分片逻辑都要自己写，自己维护，自己扛。想象一下，如果你有8个Redis节点，某天需要加2个节点——所有客户端的分片逻辑都要改，8个节点变成10节点，hash算法得全量更新，所有数据要重新分布。这在生产环境里叫做"迁移灾难"。

更致命的是：业务代码里埋着分片逻辑，意味着每个写Redis的程序员都必须懂这套机制。一个人踩坑，全团队买单。

所以这条路的本质是：用代码复杂度换架构简洁度。 小团队起步可以玩，但业务规模上来之后，这就是技术债务的重灾区。

代理分片的思路很聪明：客户端不需要知道背后有多少台Redis，只需要连代理服务器，代理帮你把请求转发到正确的节点。

Twitter开源的Twemproxy、豌豆荚开源的Codis，都是这个路子的代表作品。

听起来很完美——业务代码零改动，代理层统一管理，看起来是个优雅的解决方案。

但代理层本身就是瓶颈。

想象一下：你有100个客户端连接，每秒10万请求，全部打到一台代理上。代理成了所有流量的必经之路，它一挂，全局不可用。更要命的是，Twemproxy不支持动态扩容，Codis虽然支持，但每次扩缩容都需要人工介入，过程堪比做手术。

得物技术团队在文章里提到，他们的自建Redis早期就用了代理架构，后来花了大量精力做自动化运维：工单审批通过后自动执行集群部署、扩容、迁移，整个流程分钟级完成。这说明什么？代理分片本身没问题，但你需要给它配上一套完善的自动化平台，否则运维成本会吃掉你所有省下的架构简洁性。

这条路的本质是：用集中式管理换分布式复杂度。 如果你的团队没有能力建设配套平台，用代理分片就是在给自己挖深坑。

Redis Cluster是Redis官方在3.0版本推出的集群方案，核心设计思路是去中心化：没有单点代理，每个节点都可以接收请求，节点之间通过 gossip 协议互相感知，自动进行故障检测和转移。

分片用的是哈希槽（Hash Slot）机制：总共16384个槽，每个节点负责一部分。扩容时，只需要迁移部分槽的数据，不需要动其他节点。

这个设计解决了很多问题：

但Redis Cluster也有它的软肋：只支持单个Redis数据库（db0），不支持跨节点的事务和Lua脚本（除非用Cluster-aware的客户端），而且，网络分区一旦发生，集群就会进入不可用状态。