Redis集群高可用搭建实战：哨兵模式与Cluster分片架构对比

Redis作为高频访问的内存数据库，单节点部署无法满足生产环境的高可用和容量扩展需求。Redis Sentinel哨兵模式通过自动故障检测与主从切换实现高可用，Redis Cluster通过数据分片实现水平扩展。两种架构在部署复杂度、数据一致性、容量上限等方面差异显著。本文通过实际搭建对比两种方案的配置流程和运维要点。

Redis Sentinel哨兵模式搭建

Sentinel架构由一组Sentinel进程监控Redis主从节点，当主节点故障时自动选举新主节点并通知客户端切换。最小可用配置为1主1从1哨兵，生产环境推荐1主2从3哨兵。

主节点配置 redis-master.conf：

port 6379
bind 0.0.0.0
protected-mode no
daemonize yes
pidfile /var/run/redis-master.pid
logfile /var/log/redis/redis-master.log
dir /data/redis/master
appendonly yes
appendfsync everysec
requirepass YourStrongPassword
masterauth YourStrongPassword

从节点配置 redis-slave-1.conf：

port 6380
bind 0.0.0.0
daemonize yes
pidfile /var/run/redis-slave-1.pid
logfile /var/log/redis/redis-slave-1.log
dir /data/redis/slave-1
replicaof 192.168.1.10 6379
masterauth YourStrongPassword
requirepass YourStrongPassword
appendonly yes
appendfsync everysec

Sentinel配置 sentinel.conf：

port 26379
daemonize yes
dir /data/redis/sentinel
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel auth-pass mymaster YourStrongPassword
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 30000

关键参数说明：down-after-milliseconds设置主观下线判定阈值（5000ms，即5秒无响应判定为故障）；parallel-syncs控制故障切换后同时同步新主数据的从节点数量（设为1避免同步风暴）；quorum设为2表示至少2个Sentinel同意才能判定客观下线并触发故障切换。

# 启动顺序：主节点 -> 从节点 -> 哨兵
redis-server redis-master.conf
redis-server redis-slave-1.conf
redis-server redis-slave-2.conf
redis-sentinel sentinel.conf

# 查看哨兵状态
redis-cli -p 26379 sentinel master mymaster
redis-cli -p 26379 sentinel replicas mymaster
redis-cli -p 26379 sentinel sentinels mymaster

Redis Cluster分片集群搭建

Redis Cluster将数据分布在多个节点上，通过哈希槽（16384个槽）实现数据分片。每个节点负责一部分槽，客户端可以连接任意节点，节点会根据槽位重定向到正确节点。最小Cluster配置为3主3从6个节点。

节点配置 redis-cluster-7000.conf（其他节点修改端口和目录）：

port 7000
bind 0.0.0.0
daemonize yes
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-node-timeout 5000
cluster-announce-ip 192.168.1.10
cluster-announce-port 7000
cluster-announce-bus-port 17000
appendonly yes
appendfsync everysec
dir /data/redis/cluster-7000
requirepass YourStrongPassword
masterauth YourStrongPassword

# 启动所有节点
for port in 7000 7001 7002 7003 7004 7005; do
    redis-server redis-cluster-${port}.conf
done

# 创建集群（3主3从）
redis-cli --cluster create   192.168.1.10:7000 192.168.1.10:7001 192.168.1.10:7002   192.168.1.10:7003 192.168.1.10:7004 192.168.1.10:7005   --cluster-replicas 1 -a YourStrongPassword

# 检查集群状态
redis-cli -p 7000 -a YourStrongPassword cluster info
redis-cli -p 7000 -a YourStrongPassword cluster nodes

# 查看槽位分布
redis-cli -p 7000 -a YourStrongPassword cluster slots

–cluster-replicas 1表示每个主节点分配1个从节点，共3主3从。集群创建后16384个哈希槽自动均匀分配到3个主节点。cluster-node-timeout设置节点超时判定（5000ms），超时后节点被标记为PFAIL状态。

数据分片与哈希槽原理

Redis Cluster使用CRC16算法计算key的哈希值，对16384取模确定槽位。每个key映射到固定的槽，槽分布在固定节点上，实现数据分片。

# 查看key所在槽位
redis-cli -p 7000 -a YourStrongPassword cluster keyslot user:1001
# 返回: (integer) 12657

# 当key不在当前节点的槽位范围时，返回MOVED重定向
redis-cli -p 7000 -a YourStrongPassword set user:1001 "alice"
# (error) MOVED 12657 192.168.1.10:7002

# 使用-c参数自动跟随重定向
redis-cli -c -p 7000 -a YourStrongPassword set user:1001 "alice"
# OK

# 使用Hash Tag确保多个key在同一槽位
# 用{}包裹的字符串参与哈希计算
redis-cli -c -p 7000 -a YourStrongPassword set {user:1001}:profile "data"
redis-cli -c -p 7000 -a YourStrongPassword set {user:1001}:settings "json"
# 这两个key在同一槽位，可在同一节点上执行MGET等多键操作

故障切换与扩容操作

模拟主节点故障测试自动切换：

# 查看当前集群节点状态
redis-cli -p 7000 -a YourStrongPassword cluster nodes | grep master

# 关闭7000端口主节点
redis-cli -p 7000 -a YourStrongPassword shutdown nosave

# 等待cluster-node-timeout后查看从节点是否提升为主节点
sleep 6
redis-cli -p 7001 -a YourStrongPassword cluster nodes

# 恢复原节点后作为从节点加入
redis-server redis-cluster-7000.conf
# Cluster自动将其配置为新主的从节点

集群扩容添加新节点：

# 启动新节点
redis-server redis-cluster-7006.conf
redis-server redis-cluster-7007.conf

# 将7006作为主节点加入集群
redis-cli --cluster add-node 192.168.1.10:7006 192.168.1.10:7000   -a YourStrongPassword

# 将7007作为7006的从节点加入
redis-cli --cluster add-node 192.168.1.10:7007 192.168.1.10:7000   --cluster-slave --cluster-master-id <7006的节点ID>   -a YourStrongPassword

# 重新分片，将部分槽位迁移到新节点
redis-cli --cluster reshard 192.168.1.10:7000   --cluster-from all   --cluster-to <7006的节点ID>   --cluster-slots 4096   -a YourStrongPassword

# 平衡槽位分布
redis-cli --cluster rebalance 192.168.1.10:7000   -a YourStrongPassword

两种架构对比与选型建议

Sentinel模式与Cluster模式的核心差异：

• 容量上限：Sentinel受单机内存限制，Cluster可线性扩展
• 数据一致性：Sentinel异步复制可能丢数据，Cluster同样异步但故障切换更快
• 多键操作：Sentinel支持所有多键命令，Cluster需Hash Tag保证同槽
• 客户端复杂度：Sentinel客户端较简单，Cluster需支持MOVED/ASK重定向
• 部署运维：Sentinel配置简单，Cluster节点管理复杂
• 适用场景：Sentinel适合数据量小、高可用优先的场景；Cluster适合数据量大、需水平扩展的场景

数据量在单机内存可承受范围内（通常64GB以内）、多键操作频繁时选择Sentinel模式。数据量持续增长、需要横向扩展时选择Cluster模式。两者也可以组合使用：Cluster分片管理大容量数据，每个分片的主从节点之间使用Sentinel监控实现双保险。实际选型应基于数据规模预估、运维团队能力和业务对多键操作的需求综合判断。