如何确保CentOS Redis的高可用性

在 CentOS 上保障 Redis 高可用的核心思路与方案选型

• 生产上常用三种架构：主从复制（读写分离、基础容灾）、哨兵模式（自动故障转移）、Redis Cluster（分片 + 高可用）。主从是基础，哨兵解决主节点自动切换，Cluster 同时解决容量与可用性。建议至少部署3 个哨兵节点且跨物理机，避免单点。

方案一 主从复制要点与验证

• 适用：读写分离、读多写少、可接受短时人工介入的场景。
• 主节点关键配置（/etc/redis.conf）：
  • 监听与认证：bind 0.0.0.0，port 6379，requirepass your_master_password
  • 数据安全：appendonly yes
• 从节点关键配置：
  • 复制指向：replicaof < master_ip> 6379（Redis 5+ 使用 replicaof；旧版为 slaveof）
  • 认证同步：masterauth your_master_password
  • 只读：replica-read-only yes
• 启动与验证：
  • systemctl 启动各实例后，连接主库执行：info replication，应见 role:master 与 connected_slaves=N
  • 连接从库执行：info replication，应见 role:slave、master_host/master_port 与 master_link_status:up
  • 主库写入 key，验证从库同步一致。

方案二 哨兵模式自动故障转移

• 适用：需要主库宕机后自动切换且保持对外写入能力的场景。
• 部署要点：
  • 至少3 个哨兵分布在不同机器，监控同一主库；建议 Redis 主从已就绪再启动哨兵。
  • 哨兵配置（/etc/redis-sentinel.conf 或 sentinel.conf）：
    • 监控对象：sentinel monitor mymaster < master_ip> 6379 2（至少 2 票主观下线才触发客观下线）
    • 故障阈值：sentinel down-after-milliseconds mymaster 5000
    • 切换超时：sentinel failover-timeout mymaster 60000
    • 并行同步：sentinel parallel-syncs mymaster 1
    • 认证（若启用）：sentinel auth-pass mymaster your_master_password
  • 启动与验证：
    • 启动：redis-sentinel /path/sentinel.conf（或 systemctl 启动 redis-sentinel）
    • 状态检查：redis-cli -p 26379 sentinel master mymaster、sentinel slaves mymaster、sentinel get-master-addr-by-name mymaster
    • 故障演练：停止主库，观察是否自动选出新主并对外提供写服务。

方案三 Redis Cluster 分片高可用

• 适用：数据量大、写入并发高，需要水平扩展且具备自动故障转移与分片容错的场景。
• 部署要点（示例 6 节点：3 主 3 从）：
  • 每个节点启用集群：cluster-enabled yes，cluster-config-file nodes-.conf，cluster-node-timeout 5000，appendonly yes
  • 分别启动 6 个实例（端口如 7001–7006）
  • 一键建簇：redis-cli --cluster create ip:7001 ip:7002 … --cluster-replicas 1
  • 验证：cluster info、cluster nodes，确认每个主有从且状态正常。

网络与安全加固清单

• 防火墙放行：至少开放 6379/TCP（Redis） 与 26379/TCP（Sentinel）；云环境同步放通安全组入站规则。示例：firewall-cmd --add-port=6379/tcp --permanent & & firewall-cmd --reload
• 绑定与保护：生产建议 bind 内网地址或 0.0.0.0 并配合 requirepass；公网不建议暴露 6379，可通过 SSH 隧道或内网代理访问。
• 最小权限：为应用创建专用 Redis 用户/密码，避免使用 root 运行；限制来源 IP。
• 持久化与恢复：开启 AOF（appendonly yes），定期备份 RDB/AOF；故障恢复优先从持久化文件拉起，再接入集群/哨兵。

监控与演练

• 监控指标：主从偏移量（master_repl_offset）、复制延迟（lag）、哨兵主观/客观下线计数、节点存活与主观下线时长。
• 告警策略：主库 down、哨兵 ODOWN、复制 lag 持续升高、AOF 写入失败等触发告警。
• 定期演练：每季度至少一次主库宕机切换演练与从库扩容/替换演练，验证切换时效与数据一致性；演练后更新拓扑与应急手册。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！