Redis集群到底是怎么搭建的，里面原理又是啥，简单聊聊redis集群部署那些事儿

说到Redis集群，咱们可以把它想象成一个小团队，单机的Redis就像是一个超级能干的个人，所有活儿都他一个人干，数据也都记在他一个人的脑子里，但万一他生病了（服务器宕机）或者要处理的活儿太多了（高并发），那就麻烦了，Redis集群就是为了解决这个问题而生的，它相当于组建了一个团队，把数据和任务分摊到多个人（多个Redis节点）身上，这样既能分担压力，又能保证即使有一两个人请假,团队照样能运转。

Redis集群是怎么搭建的？—— 动手组“团队”

搭建一个Redis集群，听起来高大上，其实步骤不算太复杂，核心就是让多个Redis实例认识彼此，并分配好各自的任务，咱们一步步来看（这里以最经典的3主3从集群为例）：

1. 准备“团队成员”：你需要准备6个Redis服务实例，这6个实例可以跑在同一台机器的不同端口上（比如7001到7006，适合测试），也可以分布在不同的服务器上（生产环境推荐）,关键是要确保它们之间的网络是通的。
2. 配置“团队规则”：给每个Redis实例都写一个配置文件，这个文件里要明确告诉它：“嘿，你是一个集群节点”（cluster-enabled yes），还要告诉它你的端口号、持久化文件存哪里（dbfilename）、日志文件存哪里等等，最重要的是，每个节点都要有一个集群配置文件（通常叫nodes.conf），这个文件不用你手动写，集群自己会维护,里面记录了团队的所有成员信息和状态。
3. 让“团队成员”握手认识：光启动6个实例，它们还是孤立的，你需要一个“介绍人”，让它们彼此认识，Redis提供了一个叫redis-cli的工具，用一条命令就能搞定： redis-cli --cluster create 192.168.1.101:7001 192.168.1.101:7002 ... 192.168.1.102:7006 --cluster-replicas 1 这条命令的意思是：把后面列的6个节点组成一个集群，并且--cluster-replicas 1表示每个主节点配1个从节点，所以会自动形成3个主节点和3个从节点的结构，执行命令后，工具会给你推荐一个主从分配方案，你确认一下，输入yes，它们就会开始握手、交换信息,最终形成一个集群。
4. 验证团队工作：用redis-cli连接上任意一个节点（记得加-c参数，表示以集群模式连接），随便存一个数据，比如set mykey hello，你可能会发现，虽然你连接的是7001端口，但这个key可能被存到了7002节点上，这就是集群在正常工作——它根据规则把数据分配到了合适的节点。

这样,一个最简单的Redis集群就搭好了。

里面的原理又是啥？—— 团队的“分工协作”机制

这个团队能高效协作，靠的是三样法宝：分片、高可用和路由。

1. 数据分片（Sharding）—— 把活儿分下去 团队不能吃大锅饭，得把数据合理地分给每个主节点，Redis集群用的是一种叫哈希槽（Hash Slot） 的机制来分活儿的，它把整个数据空间（0-16383）分成了16384个槽位，可以想象成16384个抽屉，集群搭建时，这些槽位会尽量平均地分配给各个主节点，比如3个主节点，可能分别管理0-5460，5461-10922，10923-16383号抽屉。 当你存一个数据时，集群会用一个公式（CRC16算法）算一下这个key的哈希值，然后对16384取模，得到一个介于0-16383之间的数，这个数就决定了你的数据应该放进哪个“抽屉”，进而就知道该由哪个主节点来负责存储了,这就实现了数据的分布式存储。

   

2. 高可用（High Availability）—— 有人病倒了怎么办？ 光有主节点干活还不够，万一某个主节点宕机了，它负责的那部分数据和槽位不就没人管了吗？所以需要“备份人员”，也就是从节点，每个主节点都可以有一个或多个从节点，从节点会实时复制主节点的数据，相当于主节点的完整备份。 集群会持续监控所有节点的状态，如果某个主节点被判断为“失联”了（通过一种叫Gossip协议的机制，节点之间会互相八卦、传递消息来感知彼此的健康状态），那么它的一个从节点就会在大家的投票同意下，“升职”成为新的主节点，接管原来主节点负责的所有槽位和数据，这样，服务就能在极短的时间内恢复，对外界来说几乎感觉不到故障,这就是高可用。

3. 客户端路由（Client-Side Routing）—— 找对负责人 在集群里，数据是分散的，客户端怎么知道要把一个set命令发给哪个节点呢？有两种方式：

   • 重定向：客户端可能随便连上一个节点（比如节点A）发命令，如果这个key不属于节点A管的槽位，节点A不会说“我不知道”，而是会礼貌地告诉客户端：“这个key不归我管，你应该去找节点B，这是它的地址”，客户端收到这个“重定向”指令后，就会重新连接节点B去执行命令，聪明的客户端库会把这个映射关系缓存下来,下次就直接找对门了。
   • 智能客户端：更高效的方式是使用支持集群的“智能”客户端库，这种客户端在启动时，会先获取一份整个集群的“槽位-节点”映射表并缓存在本地，当要操作一个key时，它自己先在本地算出这个key属于哪个槽，然后直接连接正确的节点发送命令,省去了重定向的步骤。

聊聊部署那些事儿—— 实战中的注意事项

了解了原理，部署时心里就有谱了,但还有些细节要注意：

• 节点数量：至少需要3个主节点才能保证集群的健壮性（因为主节点选举需要超过半数的节点同意）,从节点数量根据你对可靠性的要求来定。
• 网络安全：生产环境中，节点之间通信的端口（通常是客户端端口+10000，比如7001的集群总线端口是17001）一定要用防火墙保护好，不能让外网访问,否则有安全风险。
• 运维命令：要学会常用的集群运维命令，比如查看集群状态cluster info，查看节点信息cluster nodes，手动进行故障转移（比如升级主节点时）等。
• 不是万能药：Redis集群虽然强大，但也有局限，比如它不支持同时操作多个key的事务（除非这些key在同一个节点），pub/sub功能在某些版本下也有使用限制,所以业务设计时要避开这些坑。

Redis集群就是一个通过数据分片来扩展容量和性能，通过主从复制和故障转移来保证高可用的分布式解决方案，把它理解成一个分工明确、有备份计划的团队,很多概念就清晰了。