Redis集群：分布式高可用存储方案

Redis集群：分布式高可用存储方案

随着互联网业务的快速迭代与用户规模的持续增长，数据量级与并发访问量呈现爆发式攀升，单机Redis部署逐渐暴露出明显短板，难以突破内存上限、性能瓶颈与单点故障的三重限制，无法满足企业级业务对高可用、高并发、海量数据存储的核心需求。Redis集群（Cluster）作为Redis官方推出的分布式解决方案，通过数据分片 技术实现存储容量的水平扩展，依托多主多从架构构建高可用保障体系，凭借其高效、可靠的特性，成为企业级高并发、海量数据场景下的核心存储支撑，广泛应用于电商、金融、社交等各类主流业务领域。

一、Redis 集群基本概念

Redis集群是由多个独立Redis节点相互连接、协同工作组成的分布式数据库系统，其核心设计理念是将海量数据分散存储到不同节点，在提升存储容量的同时，兼顾数据的可靠性与访问性能，实现"分而治之"的分布式管理模式。

• 核心架构 ：采用多主多从的分布式架构，集群中存在多个主节点，每个主节点独立负责一部分数据的读写请求，同时为每个主节点搭配若干个从节点，从节点实时同步主节点的数据，形成独立的"分片单元"，主从节点之间通过复制机制保障数据一致性。

• 核心价值：

  1. 水平扩展：打破单机Redis的内存限制，支持PB级海量数据存储，企业可根据业务增长需求，按需新增节点实现扩容，无需停机维护，不影响业务正常运行。

  2. 高可用：具备完善的故障自动转移机制，当主节点因硬件故障、网络中断等原因宕机时，其对应的从节点会自动晋升为主节点，无需人工干预，确保业务服务不中断，提升系统稳定性。

  3. 读写分离：采用主从分工模式，主节点专门处理写请求，从节点专注于分担读请求，有效分摊集群的并发压力，提升整体访问性能，适配高并发读场景。

• 与哨兵区别：Redis哨兵机制仅能解决主从架构的高可用问题，通过监控主节点状态实现故障转移，但无法实现数据分片，仍受限于单机存储容量；而Redis集群在哨兵机制的基础上，新增数据分片功能，同时兼顾水平扩展与故障转移，更适用于海量数据、高并发的分布式场景。

二、数据分片：集群核心算法

数据分片是Redis集群实现水平扩展的核心，其核心作用是决定每个key在集群中的存储位置，确保数据均匀分布在各个节点，避免单个节点负载过高。Redis摒弃了传统哈希求余、一致性哈希的固有缺陷，采用更为高效、灵活的**哈希槽（Hash Slot）**算法，成为集群数据分配的核心方案。

1. 传统哈希求余

传统哈希求余算法的核心逻辑是通过key哈希值%节点数的计算方式，将key分配到对应节点。该算法实现简单，但存在明显弊端：当集群节点数量发生变化（扩容或缩容）时，所有key的哈希计算结果都会改变，导致几乎所有数据都需要全量迁移，迁移成本极高，且迁移过程中可能影响业务可用性。

2. 一致性哈希

为解决传统哈希求余的扩容痛点，一致性哈希算法应运而生。该算法将节点与key均映射到一个虚拟的哈希环上，通过计算key的哈希值确定其在哈希环上的位置，进而分配到相邻的节点。其优势是节点扩容时仅需迁移少量相邻数据，但仍存在不足：当节点分布不均时，容易出现数据倾斜问题，部分节点存储大量数据，导致负载不均衡。

3. Redis 哈希槽（官方方案）

• 固定槽位 ：Redis集群预设了16384 个哈希槽（编号范围为0~16383），所有key都会通过哈希计算映射到这16384个槽位中的一个，槽位成为数据分配的基本单元。

• 映射公式 ：采用CRC16校验算法计算key的哈希值，再通过hash_slot = crc16(key) % 16384的公式，将key映射到对应的哈希槽，确保映射结果的唯一性与均匀性。

• 分配规则：集群初始化或扩容时，会将16384个哈希槽均匀分配给各个主节点，每个主节点负责一部分固定的槽位，从节点则同步对应主节点的槽位数据，确保数据冗余。其核心优势是分配均匀、扩容灵活，数据迁移仅需移动槽位对应的部分数据，无需全量迁移，且迁移过程可控，完美解决了传统哈希算法的痛点。

三、Docker 搭建 Redis 集群

在生产环境中，为了简化部署流程、提升环境一致性，常用Docker容器化技术快速部署Redis集群。本次以3 主 6 从（3个主节点、6个从节点）的架构为例，详细介绍Redis集群的搭建流程，该架构可满足中小规模企业的高可用、高并发需求。

1. 环境准备

首先需在服务器上安装Docker与Docker Compose工具，Docker用于创建和管理Redis容器，Docker Compose用于批量启动多个节点，提升部署效率。安装完成后，拉取Redis 5.0.9镜像（该版本为稳定版，兼容性强，适合生产环境使用），确保镜像拉取成功后再进行后续操作。

2. 节点配置

每个Redis节点需开启集群模式，配置文件需包含集群相关核心参数，确保节点之间能够正常通信、数据同步。核心配置如下，可根据实际业务需求调整部分参数：

port 6379
cluster-enabled yes          # 开启集群模式，必填参数
cluster-config-file nodes.conf  # 集群配置文件路径，自动生成和更新
cluster-node-timeout 5000    # 节点超时时间，单位毫秒，超时则判定为节点故障
bind 0.0.0.0                # 绑定所有IP，允许外部访问
protected-mode no            # 关闭保护模式，便于集群节点通信
daemonize no                 # 容器中禁止后台运行，避免容器退出

3. 启动节点

通过Docker Compose编写配置文件，定义9个Redis容器（3主6从），为每个容器分配固定IP地址，确保集群内所有节点能够相互ping通，避免因网络问题导致集群搭建失败。配置完成后，执行docker-compose up -d命令，批量启动所有节点，启动后可通过docker ps命令查看节点运行状态。

4. 构建集群

节点启动成功后，需执行集群创建命令，指定主从节点比例，让Redis自动分配主从关系与哈希槽。具体命令如下，其中--cluster-replicas 2表示为每个主节点分配2个从节点：

redis-cli --cluster create 
172.30.0.101:6379 172.30.0.102:6379 172.30.0.103:6379 
172.30.0.104:6379 172.30.0.105:6379 172.30.0.106:6379 
172.30.0.107:6379 172.30.0.108:6379 172.30.0.109:6379 
--cluster-replicas 2  # 每个主节点分配2个从节点，确保数据冗余

5. 集群验证

集群创建完成后，需进行验证确保集群正常运行。执行cluster nodes命令，可查看所有节点的主从关系、哈希槽分配情况以及节点状态；执行cluster info命令，可查看集群整体状态，包括槽位分配情况、节点数量等，确认所有槽位均已分配，主从同步正常，集群搭建完成。

四、集群故障自动转移

Redis集群内置完善的故障检测与Raft选举机制，无需人工干预，即可在主节点宕机时自动完成故障转移，确保集群服务不中断，这是集群高可用特性的核心体现。整个故障转移过程分为四个步骤，流程清晰、高效可靠：

1. 主观下线（SDown）：集群中的每个节点会定期向其他节点发送心跳包，检测节点状态。当单个节点检测到主节点无响应，且持续时间超过集群配置的超时时间（cluster-node-timeout）时，会将该主节点标记为主观下线，即单个节点认为该主节点已故障。

2. 客观下线（ODown）：单个节点标记主节点为主观下线后，会将该信息同步给集群中的其他节点。当超过半数的主节点都认为该主节点已故障时，会确认该主节点为客观下线，即集群共识该主节点已无法正常提供服务。

3. Raft 选举 ：主节点被确认客观下线后，其对应的所有从节点会参与新主节点的竞选，采用Raft选举机制确定新主。选举过程中，优先选择复制偏移量最大、优先级最高、run id最小的从节点作为新主，确保新主节点的数据最完整、最可靠。

4. 新主上岗：新主节点选举产生后，会接管原主节点负责的所有哈希槽，开始处理读写请求；其他从节点会自动改连新主节点，同步新主节点的数据；若旧主节点后续恢复正常，会自动变为新主节点的从节点，参与数据同步，不再承担主节点职责。

五、集群扩容：新增节点

随着业务持续增长，数据量与并发量不断提升，原有集群节点的负载会逐渐过高，此时需要通过扩容新增节点，分担集群压力、提升存储容量。集群扩容操作无需停机，可在线完成，具体按以下步骤操作：

1. 新增节点：按照集群现有节点的配置，启动新的主从节点（通常新增1主1从或1主多从），确保新节点的配置与现有集群节点一致，且能够与集群内所有节点正常通信，启动后将新节点加入现有集群。

2. 重分配槽 ：执行redis-cli --cluster reshard命令，进入哈希槽重分配流程，指定新主节点的IP和端口，以及需要迁移的槽位数量，系统会自动从旧主节点迁移部分哈希槽到新主节点，迁移过程为在线迁移，不影响业务的正常读写。

3. 验证状态 ：槽位迁移完成后，执行cluster nodes和cluster info命令，查看新主节点的哈希槽分配情况、从节点同步状态，确认槽位分配均匀、数据同步正常，扩容操作完成。

六、集群缩容：下线节点

当业务缩减、数据量减少，或者集群节点出现硬件老化等问题时，需要进行集群缩容，下线多余节点，优化集群资源配置。缩容操作需确保数据不丢失、集群槽位完整，具体按以下步骤操作：

1. 迁移槽 ：首先将待删除主节点负责的所有哈希槽，通过reshard命令全部分配到集群中其他健康的主节点，确保待删除节点不再承担任何槽位的存储与处理职责，迁移完成后确认该节点无任何槽位。

2. 删除节点 ：执行redis-cli --cluster del-node命令，指定待删除节点的IP和端口，将无槽节点从集群中移除，移除后该节点不再参与集群的任何操作。

3. 验证完整性 ：节点删除完成后，执行cluster nodes和cluster info命令，确认集群哈希槽完整（16384个槽位全部正常分配），无数据丢失，所有剩余节点状态正常、通信顺畅，缩容操作完成。

七、集群客户端连接

Redis集群客户端会自动根据key的哈希值计算对应的哈希槽，进而路由到负责该槽位的主节点或从节点，无需人工指定节点地址，简化了客户端的连接与使用。以下介绍两种主流开发语言的集群连接方式：

Java（Jedis）

使用Jedis客户端连接Redis集群，需引入Jedis集群依赖，通过配置集群节点地址集合，创建JedisCluster实例，即可实现集群的读写操作，客户端会自动完成槽位路由与故障重试。示例代码如下：

// 引入Jedis集群依赖后，配置集群节点地址
Set<HostAndPort> nodes = new HashSet<>();
nodes.add(new HostAndPort("127.0.0.1", 6379));
nodes.add(new HostAndPort("127.0.0.1", 6380));
nodes.add(new HostAndPort("127.0.0.1", 6381));
// 创建JedisCluster实例，默认自带连接池，可配置连接超时、最大连接数等参数
JedisCluster cluster = new JedisCluster(nodes);
// 执行读写操作，客户端自动路由到对应节点
cluster.set("key", "value");
String result = cluster.get("key");

Spring Boot

在Spring Boot项目中，可通过整合Spring Data Redis，简化Redis集群的连接配置。只需在application.yml配置文件中指定集群节点地址、连接池参数等，RedisTemplate会自动实现集群的槽位路由、读写分离与故障转移，开发人员无需关注底层实现，直接通过RedisTemplate操作集群即可。

结语

Redis集群通过哈希槽分片技术有效突破了单机Redis的存储与性能瓶颈，依托多主多从架构与自动故障转移机制，构建了高可用、高并发的分布式存储体系，完美适配现代企业级业务中海量数据、高并发访问的核心需求。在实际应用中，合理规划集群节点数量、优化哈希槽分配与扩容缩容策略，能够充分发挥Redis集群的性能优势，同时做好节点监控、数据备份等运维工作，可进一步提升集群的稳定性与可靠性，让Redis集群成为分布式系统的核心数据底座，支撑业务持续健康发展。