红色的思维里聊聊Redis单例和集群那些事儿，怎么选怎么用还挺复杂

微信公众号“红色的思维”）

那天有个朋友问我,说他们项目想用Redis，但纠结于是搞个单机的Redis实例，还是上一套集群方案，他说看网上文章，有的说单机简单够用，有的说集群才是王道，感觉这事儿还挺复杂的，不知道怎么选，我一听，这不就是典型的“手里有把锤子，看什么都像钉子”嘛，今天咱就抛开那些高大上的术语，像聊天一样，掰扯掰扯Redis单例和集群的那些事儿。

先说说单机Redis，也就是单例模式。

你可以把它想象成你家楼下的一个超级能干的“万能杂货铺”，老板就一个人，记性特别好，你需要啥，比如一瓶酱油、一包盐，喊一声，老板立马从柜台里给你拿出来，速度快得很，这个杂货铺有几个特别大的好处：

第一,简单省心，就一个铺面，一个老板，你不用操心他们内部怎么协调，怎么分东西，部署、维护起来也容易，出了问题，你就找这一个人就行，对于我们很多小项目、初创公司，或者就是做个简单的缓存、存个会话（Session）什么的，这个杂货铺完全够用了，没必要兴师动众。

第二,东西保证不乱，因为所有东西都放在一个老板脑子里（也就是一个进程里），他保证你后放进去的酱油不会跑到盐盒子前面去（指的是数据强一致性），对于一些对数据顺序、一致性要求很高的场景，单机版有它先天的优势。

这个万能杂货铺也有它的软肋,最要命的有两点：一是怕老板生病，万一老板今天感冒了，关门歇业，那整个小区的人都买不到东西了，服务就彻底中断了，这就是“单点故障”，二是铺面容量有限，老板的柜台和仓库就那么大，如果整个小区突然变成几万人的大型社区，每天要买的东西海了去了，老板一个人肯定记不住，仓库也堆不下，这时候就力不从心了，会变得非常慢，甚至“崩溃”。

那怎么办呢？这时候就得请出“Redis集群”这个“大型连锁超市”了。

这个超市不再是只有一个老板的杂货铺了,它是由好多家分店（多个节点）组成的，每家分店都负责卖一部分商品（数据分片），A分店只卖粮油调味品，B分店只卖生鲜果蔬，C分店只卖日用百货，你想买啥，得先看看你要买的东西属于哪一类，然后去对应的分店。

这样一来,上面单机版的两个问题就迎刃而解了。不怕某个“老板”生病，就算A分店因为装修临时关门了（节点宕机），你还可以去B分店买水果，去C分店买毛巾，整个超市大部分功能还是正常的（高可用），通常集群还会有“备用店员”（副本节点），随时准备顶上去。容量问题解决了，一个分店库存满了？没关系，我们再开一家D分店嘛，可以不断地横向扩展，理论上容量可以非常大。

开大型超市肯定比开杂货铺要复杂得多,集群也有它的“麻烦事”：

第一,架构变复杂了，你得有个“超市导购系统”（比如Redis Cluster的客户端或者代理），告诉顾客该去哪个分店买东西，这个系统本身也可能成为瓶颈或者故障点，部署、监控、维护的成本也大大增加了。

第二,有些操作会受限，在杂货铺里，你可以让老板“把酱油和醋打包成一个套餐卖给我”（原子操作多个Key），但在超市里，酱油在A分店，醋在B分店，你想原子性地同时操作它们，就非常困难了，所以集群环境下，涉及多个Key的复杂事务或者跨分片操作，要么不支持，要么很麻烦。

第三,网络开销大了，数据分布在不同节点上，节点之间需要不停地通信，同步信息、选举主从啥的，这会占用一些网络带宽和资源。

到底该怎么选呢？

这事儿真没标准答案,完全看你的“小区”实际情况，红色的思维里建议，你可以问自己几个问题：

1. 你的数据量有多大？ 如果几个G就搞定了，未来增长也缓慢，单机版内存现在都很大，够用了，但要是预计未来数据是TB级别的，那还是早点考虑集群吧。
2. 你能容忍服务中断吗？ 如果你的应用停个几分钟重启一下没关系（比如一些内部管理系统），单机版配上定期备份，也能接受，但如果是电商网站、在线支付这种，一分钟都不能停，那就必须上集群保证高可用。
3. 你的业务复杂吗？ 是不是严重依赖Redis的那些跨Key事务？如果业务逻辑很简单，就是简单的SET/GET，那集群很合适，如果业务复杂，用了很多高级功能，就得仔细评估集群是否支持了。
4. 你和你的团队能hold住吗？ 集群的运维需要更高的技术能力，如果团队刚开始接触Redis，从单机版开始学习、踩坑，是更稳妥的选择。

单机Redis像是个灵活高效的杂货铺,简单够用就是宝；集群Redis则是个庞大可靠的连锁超市，应对海量和高压才是它的舞台，选择没有对错，只有合适与否，别一听集群高大上就盲目跟风，也别因为单机简单就忽视未来的风险，根据自己项目的实际情况，量体裁衣，才是正道，这事儿，确实得好好琢磨琢磨。