Redis集群选型那些事儿，聊聊怎么优雅又实用地搞定方案

综合自多位互联网公司架构师的技术博客分享、社区讨论以及实际项目经验总结）

聊到Redis集群选型，这事儿说大不大，说小也不小，你要是项目初期用户量没起来，一个单机Redis可能就够用了，根本不用考虑集群这回事，但一旦业务量上来了，数据量大了，或者对可用性要求高了，比如要求服务不能随便挂掉,那你就得好好琢磨一下集群方案了。

为啥要用集群？说白了就三个核心问题：一是数据存不下了，单机内存总有上限；二是访问压力扛不住了，单机读写有瓶颈；三是怕宕机，一台机器出问题整个缓存服务就瘫痪了，选集群就是为了解决容量、性能和可用性这三大难题。

那市面上主流的方案有哪些呢？咱们别扯那些特别专业的术语,就用大白话聊聊几种常见的搞法。

第一种，老牌经典款：Redis Cluster。

这是Redis官方自己推出的“亲儿子”集群方案，你可以把它想象成把一大堆数据，用某种规则（比如对key取个模）自动分到很多个Redis小节点上，每个小节点只存一部分数据，它们之间还会互相通信,互相备份。

• 优点：官方出品，社区活跃，文档全，它能自动分数据，也能自动处理某个节点挂掉的情况（即高可用），运维工具也比较成熟，对于大多数公司来说，如果没啥特殊需求，选它最省心,不容易出大错。
• 缺点：功能上有点“阉割”，它要求一个key关联的所有数据（我们叫它多key操作）必须都落在同一个节点上，不然就报错，这就限制了某些复杂命令的使用，扩容缩容的时候需要迁移数据，虽然能自动做，但如果数据量巨大，过程可能会有点慢,需要盯着点。

（来源：Redis官方文档以及《Redis设计与实现》一书中的相关阐述）

第二种，客户端分片款：Twemproxy 或者直接在业务代码里分。

这种方案可以理解为，在Redis本身之外，你再找个“中间人”（比如Twemproxy，也叫nutcracker），或者让你的程序自己当这个“中间人”，由这个“中间人”来决定一个数据请求应该发给后端的哪一台Redis服务器。

• 优点：后端的Redis服务器就是普通的单机版，啥命令都能用，没有Redis Cluster的那些限制，架构简单明了,好理解。
• 缺点：这个“中间人”很容易成为瓶颈，而且它自己挂了就全完了（单点故障），扩容缩容是件非常痛苦的事儿，数据迁移得手动搞，搞不好服务就受影响，所以这种方案现在新项目用得越来越少了,主要是一些历史遗留系统在用。

（来源：早期大型互联网公司如Twitter、Pinterest的技术实践分享）

第三种，代理增强款：Codis。

这个可以看作是针对第二种方案的“升级补丁”，它也是引入一个代理层（Codis-Proxy），但背后做了很多工作来弥补Twemproxy的不足，它有一个管理后台，可以比较平滑地扩容缩容,数据迁移对业务影响小一些。

• 优点：相比Twemproxy，运维管理方便多了，有可视化界面，扩容没那么痛苦，对业务代码来说,就像操作一个单机Redis一样简单。
• 缺点：架构比Redis Cluster复杂，组件多（代理、管理后台、配置中心等），出问题了排查起来可能更费劲，而且毕竟是第三方开源项目,社区支持和迭代速度可能不如官方。

（来源：Codis项目官方GitHub页面及相关技术解读文章）

第四种，云服务商款：直接买云Redis集群。

如果你是把自己的服务部署在阿里云、腾讯云这些云平台上,那最简单粗暴的办法就是直接用他们提供的Redis集群服务。

• 优点：极致省心！你不用关心底层用了哪种技术方案（可能是自研的，也可能是魔改的Redis Cluster），不用管部署、监控、备份、扩容这些破事，花钱就行,稳定性通常也有保障。
• 缺点：贵！长期看成本比自己维护高，而且会被云厂商“绑住”，以后想迁到别的云或者自己机房会比较麻烦,能用的功能和性能上限也得看云厂商的脸色。

那到底该怎么选呢？

这事儿没有标准答案,得看你的实际情况。

• 如果你是技术团队实力一般的中小公司，追求稳定和可维护性，那么Redis Cluster通常是首选，它能满足绝大多数场景，跟着官方走,坑少。
• 如果你有大量的多key操作需求，或者是个存量系统，已经用了客户端分片，可以评估一下迁移到Codis的成本和收益。
• 如果你是创业公司，人手极其紧张，或者项目需要快速上线验证，别犹豫，直接上云服务，先用钱换时间和稳定性,等业务做大了再考虑优化成本的事儿。
• 至于传统的客户端分片（Twemproxy），除非有历史包袱,否则新项目真心不推荐了。

最后提醒一点，无论选哪种方案，都要提前想好数据备份和恢复的策略，以及监控报警怎么做，集群不是银弹，它解决了大问题，但也带来了新的复杂度，别等到数据丢了或者服务雪崩了才后悔莫及，总之一句话，合适的才是最好的,别为了用集群而用集群。