Redis集群搭建高可用缓存服务：从零开始的实操指南

为什么需要高可用Redis集群

很多新手把Redis当单机缓存用，一旦服务器宕机或进程崩溃，所有缓存数据丢失，业务直接受影响。
Redis集群不仅能分散读写压力，还能通过主从切换实现故障自动转移，保证整个缓存服务在部分节点出问题时依然可用。
本文基于Redis 6.x版本，用3主3从的方式搭建高可用集群。

环境准备：4台服务器怎么分配

生产环境下建议至少6台机器，但为了演示，我们可以用4台云服务器（或虚拟机）。
每台安装CentOS 7.9或Ubuntu 20.04，配置2核4G即可。
分配方案如下：

• 节点1（192.168.1.101）：Redis主节点1
• 节点2（192.168.1.102）：Redis主节点2
• 节点3（192.168.1.103）：Redis主节点3
• 节点4（192.168.1.104）：Redis从节点（为三个主节点各分配一个从节点，但只有一台从节点怎么处理？实际中一台机器可以运行多个Redis实例，用不同端口区分。我们将在节点4上启动3个Redis实例，分别作为三个主节点的从库。）

所有服务器需要防火墙开放端口：各Redis实例的端口（如6379、6380、6381），以及集群总线端口（每个端口+10000，如16379、16380、16381）。

一步步搭建Redis集群

1. 安装Redis并编译

所有节点都执行以下命令（以节点1为例）：

# 安装依赖
sudo yum install -y gcc gcc-c++ make
# 下载Redis源码
wget https://download.redis.io/releases/redis-6.2.14.tar.gz
# 解压编译
tar xzf redis-6.2.14.tar.gz
cd redis-6.2.14
make && sudo make install

安装完成后，将utils/redis_init_script复制到/etc/init.d/方便管理，或者直接用src/redis-server启动。

2. 配置文件准备

在节点1创建目录/data/redis/6379，然后编辑/etc/redis/6379.conf：

mkdir -p /data/redis/6379
vim /etc/redis/6379.conf

写入以下关键配置（其他默认）：

port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 5000
appendonly yes
appendfilename "appendonly-6379.aof"
dir /data/redis/6379

节点2、节点3配置类似，只需修改端口和目录。
节点4需要创建3个配置文件（端口6380、6381、6382），目录分别对应/data/redis/6380等，配置项同理。

3. 启动所有Redis实例

每个节点上执行（以节点1为例）：

redis-server /etc/redis/6379.conf

检查进程：ps aux | grep redis，看到redis-server *:6379 [cluster]表示启动成功。

4. 创建集群

在任意一台机器上执行（确保所有实例都启动，并且网络互通）：

redis-cli --cluster create \
  192.168.1.101:6379 \
  192.168.1.102:6379 \
  192.168.1.103:6379 \
  192.168.1.104:6380 \
  192.168.1.104:6381 \
  192.168.1.104:6382 \
  --cluster-replicas 1

这里--cluster-replicas 1表示每个主节点分配一个从节点。
命令执行后会显示分配方案，输入yes确认。

5. 验证集群状态

执行redis-cli -h 192.168.1.101 -p 6379 cluster nodes，看到每个节点都有标识（master或slave），并且从节点指向主节点。
再用redis-cli -h 192.168.1.101 -p 6379 cluster info查看集群状态，cluster_state:ok表示正常。

踩坑记录与解决方法

• 问题1：Node is not empty 错误。
• 原因：某个Redis实例之前残留旧数据或集群配置。
• 解决：删除/data/redis/*/nodes-*.conf文件并重启Redis。
• 问题2：Waiting for the cluster to join 卡住。
• 原因：防火墙未开放集群总线端口。
• 解决：检查每个节点的iptables或云服务商安全组，确保TCP端口范围包含实例端口+10000。
• 问题3：主节点宕机后从节点不能自动切换。
• 原因：cluster-node-timeout设置过短或网络延迟。
• 解决：调大超时时间至10000，并确保集群节点间时延不超过200ms。

验证缓存服务的高可用性

我们在节点1上写入一条缓存：

redis-cli -h 192.168.1.101 -p 6379 set test_key hello
redis-cli -h 192.168.1.101 -p 6379 get test_key
# 输出：hello

然后模拟故障：强制杀死节点1的Redis进程：

kill -9 $(pgrep -f "redis-server.*6379")

等待几秒，重新查看集群状态：

redis-cli -h 192.168.1.102 -p 6379 cluster nodes

可以看到原节点1的从节点（如192.168.1.104:6380）已经升级为master。
接着读取刚才的key：

redis-cli -h 192.168.1.104 -p 6380 get test_key
# 输出：hello

数据未丢失，服务正常响应。
重启节点1后它会自动以从节点身份加入集群。

如果你正在处理Redis集群搭建高可用缓存服务，建议先按本文步骤完整执行，再根据自己的环境做微调；
遇到异常时优先回看避坑和高频问题部分。
通过亲手操作，你会发现集群搭建并不神秘，关键是把配置和防火墙细节处理好。
动手试试吧！