一、Redis分布式架构与可用性基础

Redis作为高性能内存数据库，其分布式版本通过分片（Sharding）和复制（Replication）技术实现水平扩展。典型架构包含主节点（Master）和从节点（Replica），主节点处理写请求，从节点通过异步复制同步数据。这种设计天然支持读写分离，但需解决数据一致性与故障切换问题。

关键组件：

• Sentinel机制：监控主从节点状态，实现自动故障转移。当主节点宕机时，Sentinel通过投票选举新主节点，确保服务连续性。
• Cluster模式：Redis 3.0+引入的原生集群方案，支持多主多从架构，通过哈希槽（Hash Slot）分配数据，实现自动分片和负载均衡。

可用性挑战：

• 网络分区（Network Partition）可能导致脑裂（Split-Brain），即多个节点同时宣称为主节点。
• 异步复制可能引发数据丢失，尤其在主节点故障时未同步的数据可能丢失。

二、高可用性保障策略

1. 数据复制与持久化

Redis支持两种持久化方式：RDB（快照）和AOF（日志）。生产环境建议同时启用，并配置appendfsync everysec平衡性能与数据安全性。对于关键业务，可通过min-slaves-to-write和min-slaves-max-lag参数确保主节点至少有N个从节点且延迟低于阈值时才接受写操作，防止数据孤立。

配置示例：

# redis.conf
appendonly yes
appendfsync everysec
min-slaves-to-write 2
min-slaves-max-lag 10

2. 故障自动检测与切换

Sentinel通过down-after-milliseconds参数定义节点不可用判定阈值，结合quorum参数（需至少N个Sentinel同意）触发故障转移。建议部署3个以上Sentinel节点，避免单点失效。

Sentinel配置示例：

# sentinel.conf
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 180000

3. 集群模式下的数据分片与冗余

Redis Cluster将16384个哈希槽均匀分配到多个主节点，每个主节点可配置多个从节点。当主节点故障时，从节点自动晋升为主节点，槽位重新分配。需注意：

• 集群至少需要3个主节点（生产环境推荐6节点以上）。
• 跨槽位操作（如MGET跨多个键）需客户端支持或通过Hash Tag强制同一槽位。

客户端连接示例（Python）：

import redis
r = redis.RedisCluster(
    startup_nodes=[{"host": "127.0.0.1", "port": "7000"}],
    decode_responses=True
)
r.set("foo", "bar")  # 自动路由到正确节点

三、性能优化与容量规划

1. 内存管理

Redis性能高度依赖内存，需监控used_memory和maxmemory参数。当内存接近上限时，可通过maxmemory-policy（如volatile-lru、allkeys-lfu）设置淘汰策略。对于大键（Big Key），建议拆分为多个小键或使用Hash/ZSET等复合结构。

内存监控命令：

redis-cli info memory | grep used_memory_human

2. 网络延迟优化

跨机房部署时，需考虑网络延迟对复制的影响。可通过以下方式降低延迟：

• 启用repl-disable-tcp-nodelay no（默认禁用Nagle算法）。
• 使用repl-backlog-size调整复制积压缓冲区大小，防止从节点重连时需全量同步。

3. 扩容与缩容

Redis Cluster支持动态扩容，通过CLUSTER MEET命令添加新节点，再使用CLUSTER ADDSLOTS分配槽位。缩容时需先将槽位迁移至其他节点，再移除空节点。

槽位迁移示例：

redis-cli -c -h node1 CLUSTER SETSLOT 1000 NODE node2

四、监控与运维实践

1. 监控指标

关键指标包括：

• 连接数：connected_clients过高可能引发阻塞。
• 命中率：keyspace_hits/(keyspace_hits+keyspace_misses)低于90%需优化。
• 延迟：instantaneous_ops_per_sec与latest_fork_usec（RDB保存耗时）。

2. 告警策略

设置阈值告警：

• 主从延迟超过5秒。
• 内存使用率超过85%。
• 连接数超过最大连接数的80%。

3. 备份与恢复

定期备份RDB/AOF文件至远程存储，并通过redis-check-aof/redis-check-rdb验证文件完整性。恢复时需先停止服务，再替换文件并重启。

五、实际场景解决方案

场景1：电商库存系统

• 需求：高并发扣减库存，需保证强一致性。
• 方案：使用Redis Cluster单分片（所有库存键哈希到同一槽位），配合Lua脚本实现原子操作。

  -- inventory.lua
  local key = KEYS[1]
  local stock = tonumber(redis.call("GET", key))
  if stock >= tonumber(ARGV[1]) then
    return redis.call("DECRBY", key, ARGV[1])
  else
    return 0
  end

场景2：金融交易系统

• 需求：零数据丢失，允许短暂不可用。
• 方案：启用同步复制（repl-sync-master-delay 0），结合Sentinel+持久化，故障时手动切换主节点。

六、总结与建议

Redis分布式数据库的可用性需从架构设计、配置优化、监控运维三方面综合保障。建议：

1. 生产环境优先使用Cluster模式，避免手动分片。
2. 定期演练故障转移流程，验证Sentinel/Cluster行为。
3. 结合Prometheus+Grafana构建可视化监控体系。
4. 对关键业务考虑多活部署，降低单区域故障影响。

通过合理配置与持续优化，Redis分布式数据库可实现99.99%以上的可用性，满足绝大多数业务场景需求。