Redis集群高可用实战：哨兵模式与Cluster分片部署方案

Redis高可用架构选型

Redis在生产环境中单点部署风险较高，主从复制仅解决数据冗余问题，故障时需手动切换。Redis高可用方案主要有两种：Sentinel（哨兵）模式和Cluster（集群）模式。Redis缓存策略的实施依赖于稳定的高可用架构支撑。数据库高可用架构的选型直接决定系统的容灾能力。

两种模式对比：

– Sentinel模式：一主多从+哨兵监控，主节点宕机自动选举从节点升主，适合数据量中等、读写分离场景
– Cluster模式：多主多从分片存储，无中心节点，数据按16384个槽位分布，适合大数据量、高吞吐场景
– Sentinel优势：部署简单，客户端无需感知分片逻辑，支持平滑升级
– Cluster优势：水平扩展，单节点故障不影响整体可用性，数据自动均衡

Sentinel哨兵模式部署

Sentinel集群由多个Sentinel实例组成，监控主从节点健康状态。当主节点不可达时，Sentinel通过Raft协议选举leader执行故障转移。以下是一个三节点Sentinel部署配置：

# redis-26379.conf (Sentinel节点1)
port 26379
daemonize yes
pidfile /var/run/redis-sentinel-26379.pid
logfile /var/log/redis/sentinel-26379.log
dir /data/redis/sentinel

# 监控的主节点配置（master-name, ip, port, quorum）
sentinel monitor mymaster 192.168.1.10 6379 2

# 主节点密码
sentinel auth-pass mymaster YourRedisPassword

# 主节点不可达判定时间（毫秒）
sentinel down-after-milliseconds mymaster 5000

# 故障转移时同时向新主复制的从节点数
sentinel parallel-syncs mymaster 1

# 故障转移超时时间（毫秒）
sentinel failover-timeout mymaster 30000

# 通知脚本（可选）
sentinel notification-script mymaster /opt/redis/notify.sh

quorum设为2表示至少2个Sentinel同意才能判定主节点下线，避免网络分区导致的误判。三节点Sentinel中quorum=2兼顾可用性和准确性。

# 启动三个Sentinel实例
redis-server /etc/redis/sentinel-26379.conf --sentinel
redis-server /etc/redis/sentinel-26380.conf --sentinel
redis-server /etc/redis/sentinel-26381.conf --sentinel

# 查看Sentinel状态
redis-cli -p 26379
> SENTINEL master mymaster
> SENTINEL replicas mymaster
> SENTINEL sentinels mymaster

Cluster集群模式部署

Redis Cluster将数据分布在多个节点上，每个节点负责一部分哈希槽。最小集群需要3主3从共6个节点。以下使用redis-cli快速创建集群：

# 六个节点配置（以节点1为例，其余修改端口和路径）
# redis-7000.conf
port 7000
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-node-timeout 5000
appendonly yes
bind 192.168.1.10
daemonize yes

# 启动六个节点
for port in 7000 7001 7002 7003 7004 7005; do
  redis-server /etc/redis/redis-$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

# 检查集群状态
redis-cli -p 7000 CLUSTER INFO
redis-cli -p 7000 CLUSTER NODES

# 查看槽位分配
redis-cli -p 7000 CLUSTER SLOTS

–cluster-replicas 1表示每个主节点分配1个从节点，集群自动分配槽位和主从关系。16384个槽位均分到3个主节点，每个负责约5461个槽。

集群扩容与数据迁移

数据迁移实战中，Cluster模式支持在线扩容。新增节点后通过槽位迁移将数据平滑转移到新节点：

# 新增主节点7006
redis-server /etc/redis/redis-7006.conf

# 将新节点加入集群
redis-cli --cluster add-node 192.168.1.10:7006 192.168.1.10:7000

# 为新主节点添加从节点7007
redis-server /etc/redis/redis-7007.conf
redis-cli --cluster add-node 192.168.1.10:7007 192.168.1.10:7000   --cluster-slave --cluster-master-id <node-id-of-7006>

# 重新分片，迁移槽位到新节点
redis-cli --cluster reshard 192.168.1.10:7000   --cluster-from all   --cluster-to <node-id-of-7006>   --cluster-slots 1000   --cluster-yes

# 检查迁移后的集群平衡
redis-cli --cluster check 192.168.1.10:7000

客户端连接与故障转移验证

Python客户端使用redis-py连接Cluster，自动处理节点路由和故障转移：

from redis.cluster import RedisCluster, ClusterNode

# 方式1：自动发现节点
rc = RedisCluster(
    host='192.168.1.10',
    port=7000,
    password='YourRedisPassword',
    decode_responses=True
)

# 方式2：显式指定节点
nodes = [
    ClusterNode('192.168.1.10', 7000),
    ClusterNode('192.168.1.10', 7001),
    ClusterNode('192.168.1.10', 7002),
]
rc = RedisCluster(startup_nodes=nodes, password='YourRedisPassword')

# 基本操作
rc.set('user:1001', json.dumps({'name': '张三', 'age': 30}))
data = rc.get('user:1001')

# 使用Hash Tag确保多键操作落在同一节点
rc.set('{order:1001}.info', '订单信息')
rc.set('{order:1001}.items', '商品列表')
# 两个key落在同一槽位，支持MULTI/EXEC事务

Hash Tag用大括号包裹key的部分内容，Redis Cluster仅对大括号内的内容计算哈希槽。数据备份恢复方面，Cluster模式支持每个节点独立持久化RDB和AOF。SQL查询优化不适用于Redis，但合理设计key结构同样影响性能。NoSQL选型应用时，Redis Cluster的16384槽位设计支持最多1024个节点，但实际部署建议不超过1000个节点以维持集群稳定性。数据备份恢复策略上，建议每天在低峰期对每个节点执行BGSAVE，RDB文件异地存储；同时开启AOF appendfsync everysec，兼顾性能和数据安全。MySQL性能调优关注的是查询计划，Redis集群优化关注的是网络延迟和槽位均衡，两者的运维思路差异明显。