Redis集群到底好不好用？优势和那些让人头疼的地方聊聊

先说优势，为什么大家会选择用它？

最核心的优势当然是高可用性和自动故障转移，在单机版的Redis里，如果主服务器挂了，整个服务就瘫了，需要人工干预去切换，这在高并发的业务里是灾难性的，而Redis集群采用多主多从的结构，数据被分片到多个主节点上，每个主节点又有一个或多个从节点做备份，一旦某个主节点宕机，集群会自动检测到，并把它对应的一个从节点提升为新的主节点，整个过程对业务方来说几乎是透明的（可能会有一小会儿的不可写或数据延迟），这对于要求业务24小时在线的电商、社交应用来说，是至关重要的，你的购物车服务、秒杀系统,可不能因为一台机器出问题就全盘崩溃。

它解决了海量数据存储和高并发写的瓶颈，也就是水平扩展能力，单台机器的内存和CPU处理能力总是有上限的，当你的数据量达到几百GB甚至TB级别，或者写操作非常频繁时，单机Redis就扛不住了，Redis集群通过将数据分散到多个节点上，实现了“人多力量大”，你可以通过增加节点来线性地提升整个集群的数据容量和吞吐量，很多大型互联网公司都用它来支撑亿级用户和海量数据，比如一些社交媒体的时间线、游戏服务器的会话存储等。

Redis集群是去中心化的结构，它不像一些传统的主从架构，有一个绝对的“大脑”（中心节点）来管理一切，在Redis集群中，每个节点都保存着整个集群的元数据（比如哪个键在哪个分片上），节点之间通过Gossip协议互相通信，这样做的好处是，避免了单点瓶颈，整个集群的架构更加健壮,不会因为某个管理节点宕机而影响元数据服务。

好了，优势很诱人，但接下来就是那些“让人头疼”的地方了，这也是很多开发者在实际使用中踩过坑的地方。

第一个头疼点是对多键操作的支持非常不友好，在单机Redis里，你可以很方便地使用事务（MULTI/EXEC）或者Lua脚本来操作多个键，保证原子性，但在集群模式下，只有当这些键都落在同一个节点（同一个哈希槽）上时，这些操作才能执行，Redis集群通过CRC16算法计算键的哈希槽来分片，如果你试图用MGET命令一次性获取多个分散在不同节点上的键，命令会直接报错，为了解决这个问题，你不得不使用“哈希标签”（Hash Tag），就是强制让一批相关的键通过花括号{}指定相同的部分，使它们被计算到同一个槽里，但这需要你在设计键名时就做好规划，增加了设计的复杂性，而且如果标签设计不当,可能导致数据分布不均。

第二个是网络闪断或节点故障时的“惊群效应”，虽然集群有故障转移机制，但这个过程中可能会出现一些问题，当主节点宕机，从节点被提升为新主的过程中，集群会有一个短暂的不可用窗口期，更麻烦的是，如果发生网络分区（俗称“脑裂”），即集群被分割成两个无法通信的小集群，原来的一部分客户端可能还在向旧的主节点写数据，而另一部分客户端则向新的主节点写数据，当网络恢复后，就会产生数据冲突和丢失的风险，虽然Redis集群有机制来处理（通过配置参数），但理解和配置这些参数本身就有门槛,处理不当就会丢数据。

第三个是运维复杂度的显著提升，管理一个单机Redis实例和管理一个由几十个节点组成的集群，完全是两码事，你需要监控每一个节点的状态（内存、CPU、网络IO）、处理节点的扩容和缩容，而扩容缩容本身就是一个比较重的操作，虽然集群支持在线操作，但过程中会涉及大量数据的迁移，会对集群性能产生一定影响，如果操作不当甚至可能引发问题，客户端的配置也变复杂了，客户端需要能够理解集群的拓扑结构，知道该连接哪个节点，虽然大多数语言的客户端都有成熟的集群支持库，但比起连接单实例,出问题的排查路径更长。

资源成本更高，为了实现高可用，你至少需要3个主节点和3个从节点（共6个实例），这对于小项目来说，资源消耗远比一个单机实例大得多，如果你的数据量不大，并发也不高，只是为了“高可用”而强行上集群，可能有点杀鸡用牛刀的感觉,反而增加了不必要的运维负担。

总结一下

Redis集群绝对不是万金油，它好用吗？对于需要处理海量数据、承受极高并发、且对服务可用性有严苛要求的大型互联网应用来说，它是非常好用且几乎是必选的技术方案,其优势远远盖过了缺点。

但对于数据量不大、业务逻辑中涉及大量多键操作、或者团队运维能力跟不上的中小型项目来说，它的那些“头疼点”可能会让你非常痛苦，在这种情况下，或许采用主从复制+哨兵（Sentinel）模式来保证高可用，或者干脆使用代理中间件（如Codis、Twemproxy）来实现分片,会是更简单稳妥的选择。

归根结底，技术选型要看具体场景，在选择Redis集群之前，最好能清晰地评估自己的业务规模、数据增长预期和团队的技术储备，这样才能避免“上了集群才发现水土不服”的尴尬。