Redis集群那些事儿，操作步骤和实战经验全都给你讲清楚了

Redis集群这事儿，说白了就是当你的数据量太大，或者访问请求太高，一台Redis服务器顶不住了，就把多台Redis服务器组合起来一起干活，变成一个逻辑上的大数据库，这样既能存更多东西，又能承受更大的访问压力，下面我就把怎么搭建、怎么操作以及大家用血泪换来的实战经验给你捋一捋。

Redis集群是怎么一回事？

你可以把Redis集群想象成一个团队，这个团队有16384个槽位（slot），就像是16384个任务，集群启动后，会把所有这些槽位分配给团队里的各个成员（也就是一个个Redis节点），当你存一个数据时，会用一个算法（CRC16）算一下这个数据键（key）的哈希值，然后对16384取模，算出它应该属于哪个槽位，最后把这个数据存到负责这个槽位的那个节点上，取数据的时候也是同样的道理，直接去找对应的节点要，这样，数据和压力就自然分散开了，为了保证高可用，每个主节点还可以配备一个或多个从节点，主节点挂了,从节点能顶上去。

搭建Redis集群的操作步骤

这里讲的是最经典的用Redis原生命令搭建集群的方式，虽然现在有更省事的工具，但了解这个底层过程很重要，假设我们有6台服务器,打算做成三主三从的集群。

1. 准备节点：在六台机器上分别安装好Redis，并修改它们的配置文件（redis.conf），关键配置有几项：把cluster-enabled改成yes，开启集群模式；指定cluster-config-file，这个是节点自动生成的集群配置文件，别动它；设置cluster-node-timeout，这是节点间通信的超时时间,然后分别启动这六个Redis实例。

2. 节点握手：光启动还不够，它们彼此还不认识，你需要让它们互相打招呼，选其中一台，用Redis客户端连接上去，执行命令 cluster meet <ip> <port>，把其他五个节点的IP和端口都加进来，这样，它们就组成了一个网络,但这时候槽位还没分配。

3. 分配槽位：现在16384个槽位还空着呢，需要分配给三个主节点，你可以用命令手动分配，比如让节点1负责0-5460号槽位，节点2负责5461-10922号槽位，节点3负责10923-16383号槽位，分配槽位的命令是 cluster addslots，后面跟上槽位编号范围，这一步比较繁琐，所以通常我们会用Redis官方提供的Ruby脚本 redis-trib.rb 来自动完成，你只需要告诉这个脚本所有节点的地址，它就会自动帮你完成节点握手、槽位分配、主从关系设置等一系列工作,非常方便。

4. 主从关系：槽位分好后，三个主节点就开始工作了，但我们还需要设置从节点来提高可靠性，同样，用 cluster replicate 命令，在从节点上执行，后面跟上它要追随的主节点的ID（节点ID可以用cluster nodes命令查看），这样,一个三主三从的集群就基本搭建完成了。

   

血泪换来的实战经验

光搭起来不行，用起来坑不少,下面这些经验可是很多人踩过坑总结的。

1. 客户端要选对：你的应用程序连接集群，不能用普通的Redis客户端，必须用支持集群协议的客户端，比如Java的JedisCluster，Lettuce；Python的redis-py-cluster等，这些客户端会在启动时从集群获取槽位和节点的映射关系,之后就能自动把请求发送到正确的节点上。

2. 批量操作要小心：这是最容易出问题的地方！像mget、mset这种一次性操作多个key的命令，在集群里可能失效，因为这几个key很可能不存储在同一个节点上，解决方案要么是保证这批key通过哈希算法后都落在同一个槽位（比如给它们加上相同的哈希标签），要么就放弃批量命令，改用管道（pipeline）或者其他方式。

   

3. 集群扩容缩容是常态：业务增长后，可能需要增加节点，扩容时，需要用redis-trib.rb这样的工具把一部分槽位和数据从旧节点迁移到新节点上，这个过程集群是不停机的，但迁移过程中，涉及到正在迁移的槽位的key可能会短暂不可用，所以最好在业务低峰期操作,缩容也是类似的反向过程。

4. 网络抖动是大敌：cluster-node-timeout这个参数很关键，如果网络不稳定，节点间心跳超时，主节点可能被误判为下线，从而触发从节点选举，虽然数据不会丢，但可能会导致短暂的服务不可用和性能抖动,所以服务器之间的网络质量一定要好。

5. 监控不能少：一定要部署监控，盯着集群的状态，关键指标包括：集群状态（cluster info查看是否是ok）、每个节点的内存使用率、键数量、连接数、是否发生了主从切换（failover）等，一旦有节点宕机或者网络分区,能第一时间发现。

6. 不是所有命令都支持：由于数据分布在多个节点，一些需要跨节点操作的命令在集群模式下是被禁用的，比如多个key的跨库操作,设计业务时就要避开这些坑。

Redis集群功能强大，能解决单机瓶颈，但同时也引入了复杂性，上手之前，最好在测试环境充分演练，把上述的坑都踩一遍，摸清它的脾气，再应用到生产环境，这样才能真正让它成为你的得力助手。 整合自CSDN博主“程序员小灰”、掘金专栏“分布式缓存实践”、知乎问答“Redis集群有哪些坑？”等公开技术分享中的常见观点和操作描述。）