在Redis高可用架构中，核心是Sentinel和Cluster。Sentinel用于主从复制的自动故障转移，实现高可用；Cluster则支持数据分片和分布式部署。实战中，先搭建主从结构：slaveof主节点IP端口，然后配置Sentinel监控多个节点，当主节点故障时自动选举从节点为主。接着部署Cluster，使用redis-cli --cluster create命令初始化集群节点，指定节点IP端口和分片数如16384。结合Twemproxy或Codis作为代理，实现客户端分片，灵活应对流量高峰。监控用Prometheus+Grafana，告警阈值设为CPU>80%、内存>90%。这样构建的架构，能支撑百万QPS，故障恢复秒级完成。

Redis主从复制与Sentinel高可用实战

主从复制配置简单，在redis.conf中slaveof 192.168.1.100 6379，开启requirepass密码保护。Sentinel部署3个节点，sentinel monitor mymaster 192.168.1.100 6379 2，quorum设为2，down-after-milliseconds 30000。测试故障：kill主节点进程，观察日志Sentinel自动切换，客户端重连新主。实际生产中，结合keepalived实现VIP漂移，避免单点。数据一致性用wait命令同步ACK，达到最终一致性。

Redis Cluster分布式布局经验

Cluster模式下，每节点跑redis-server --cluster-enabled yes --cluster-config-file nodes.conf。创建集群：redis-cli --cluster create 10.0.0.1:7000 10.0.0.1:7001 ... --cluster-replicas 1。槽位分配均匀，16384槽。扩容时redis-cli --cluster add-node新节点 old节点，--cluster reshard重新分配槽。故障时自动转移槽位到从节点。客户端用JedisCluster或Lettuce连接，内置重试机制。实战中，从3主3从起步，流量翻倍时加节点零停机。

代理中间件提升Redis可用性

用Twemproxy部署代理，配置文件pools中定义redis服务器列表，auto_eject_hosts on自动剔除故障节点。Codis开源方案更强大，支持Dashboard管理、Proxy热更新、Group分组热迁移。实战分享：电商秒杀场景，用Codis proxy前端，backend多组Redis，pipeline批量命令降低RT。监控proxy连接数，超过阈值扩组。结合HAProxy做proxy层负载均衡，双活数据中心架构稳如老狗。

高可用架构监控与优化

用redis-exporter暴露指标，Prometheus scrape配置targets，Grafana面板显示latency、evicted_keys、rejected_connections。慢查询开启slowlog-log-slower-than 10000，日志分析优化热点key。内存优化：maxmemory-policy allkeys-lru，lazyfree-lazy-evict yes。实战中，峰值QPS 50w时，开启pipeline和hash分片，内存碎片控制在1.2以内。灾备用RDB+AOF混合，脚本定时全量同步异地。

FAQ

Q: Redis Sentinel和Cluster哪个适合高可用？
A: Sentinel适合读写分离场景，主从简单高可用；Cluster支持海量数据分片，内置高可用，选Cluster更灵活。

Q: 如何处理Redis内存不足？
A: 设置maxmemory和淘汰策略，监控used_memory，热点数据用本地缓存，定期清理过期key。

Q: Cluster扩容会丢失数据吗？
A: 不会，reshard过程迁移槽位数据，支持在线操作，客户端透明。

Q: 生产环境怎么测试故障切换？
A: 用kill -9模拟crash，chaos工程工具如Pumba注入故障，验证切换时间<10s。