👋 大家好，欢迎来到我的技术博客！
💻 作为一名热爱 Java 与软件开发的程序员，我始终相信：清晰的逻辑 + 持续的积累 = 稳健的成长。
📚 在这里，我会分享学习笔记、实战经验与技术思考，力求用简单的方式讲清楚复杂的问题。
🎯 本文将围绕Redis这个话题展开，希望能为你带来一些启发或实用的参考。
🌱 无论你是刚入门的新手，还是正在进阶的开发者，希望你都能有所收获！

---

Redis100篇 - Redis面试场景题：怎么设计一个高可用的Redis缓存系统？🔥🧠

“如果让你从零开始设计一个高可用的 Redis 缓存系统，你会怎么做？”

这道题，几乎出现在所有中高级后端/架构师岗位的面试中。它看似简单，实则是一面“照妖镜”——能瞬间照出你对缓存、高可用、容灾、监控、一致性等核心能力的理解深度。

很多候选人回答：“用 Redis Cluster 就行了！”
但面试官真正想听的是：你在真实业务压力下，如何权衡取舍、规避陷阱、保障系统在故障中依然坚挺如初？

本文将带你：
✅ 拆解“高可用缓存系统”的 6 大核心维度
✅ 对比主从、哨兵、Cluster、Proxy 等架构优劣
✅ 提供 Java 代码示例：连接池配置 + 故障自动切换 + 降级策略
✅ 嵌入 Mermaid 可视化架构图 + 容灾流程图
✅ 给出生产环境验证有效的 8 条最佳实践
✅ 附权威外链（均可正常访问）

无论你是准备面试，还是正在搭建线上系统，这篇深度指南都将助你构建一个真正高可用、可运维、抗压强的 Redis 缓存体系！🛡️

---

🎯 一、什么是“高可用”？不止是“不宕机”！

高可用（High Availability, HA）≠ 永远在线。
真正的高可用系统，需满足：

维度	要求	衡量指标
可用性	服务持续可访问	SLA ≥ 99.95%（年宕机 < 4.38 小时）
容错性	单点故障不影响整体	自动故障转移（Failover）< 30 秒
数据可靠性	缓存丢失可接受，但关键数据不丢	根据业务容忍度设计
可观测性	故障可快速定位	监控 + 告警 + 日志
可运维性	扩缩容、升级平滑	自动化工具支持

💡 缓存 vs 存储：
Redis 作为缓存，允许数据丢失（可回源 DB），但不允许服务不可用！

---

🏗️ 二、架构选型：4 种主流方案深度对比 🧩

方案 1：单机 Redis（❌ 不推荐）

• 优点：简单
• 缺点：单点故障，无高可用
• 适用：本地开发、测试环境

方案 2：主从复制 + 哨兵（Sentinel）✅

• 优点：
  • 自动故障检测与转移（Master 宕机 → Slave 升主）
  • 读写分离（客户端可读 Slave）
• 缺点：
  • 不支持自动分片，容量受限于单机内存
  • 故障转移期间短暂不可用（约 10~30 秒）
• 适用：中小规模，QPS < 10万，数据量 < 20GB

🔗 Redis Sentinel 官方文档

---

方案 3：Redis Cluster（✅ 推荐）

graph LR
    Client -->|CRC16(slot)| NodeA[Master A<br/>slots 0-5460]
    Client -->|CRC16(slot)| NodeB[Master B<br/>slots 5461-10922]
    Client -->|CRC16(slot)| NodeC[Master C<br/>slots 10923-16383]
    NodeA --> ReplicaA[Replica A]
    NodeB --> ReplicaB[Replica B]
    NodeC --> ReplicaC[Replica C]

• 优点：
  • 自动分片（16384 slots），横向扩展容量与性能
  • 去中心化，无单点瓶颈
  • 内置故障转移（基于 Gossip 协议）
• 缺点：
  • 运维复杂度高
  • 不支持多 Key 跨槽事务（除非使用 Hash Tag）
• 适用：大规模生产环境（QPS > 10万，数据量 > 50GB）

🔗 Redis Cluster 官方文档

---

方案 4：Proxy + 分片（如 Codis/Twemproxy）🔄

• 优点：
  • 对客户端透明（像操作单机 Redis）
  • 支持动态扩缩容
• 缺点：
  • 引入额外组件（Proxy、ZooKeeper），增加复杂度
  • 社区活跃度下降（Codis 已停止维护）
• 适用：已有 Proxy 架构，或需要兼容旧客户端

🔗 Codis GitHub（仅参考）
⚠️ 建议新项目优先选 Redis Cluster

---

🧪 三、Java 客户端选型：Jedis vs Lettuce 🆚

特性	Jedis	Lettuce
连接模型	同步阻塞（需连接池）	基于 Netty 的异步非阻塞
线程安全	❌（每个线程需独立连接）	✅（单实例多线程共享）
集群支持	支持（JedisCluster）	支持（RedisClusterClient）
故障恢复	手动重连	自动重连 + 拓扑刷新
Spring Boot 默认	2.x 以前	2.x 以后

💡 结论：

• 新项目 → Lettuce（更现代、资源占用低）
• 老项目迁移 → Jedis（熟悉度高）

---

💻 四、Java 代码实战：高可用连接配置 🛠️

场景：使用 Lettuce 连接 Redis Cluster

Maven 依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>io.lettuce</groupId>
    <artifactId>lettuce-core</artifactId>
</dependency>

application.yml

spring:
  redis:
    cluster:
      nodes:
        - 10.0.1.10:7000
        - 10.0.1.11:7000
        - 10.0.1.12:7000
        - 10.0.1.10:7001
        - 10.0.1.11:7001
        - 10.0.1.12:7001
      max-redirects: 3  # MOVED 重定向最大次数
    timeout: 2000ms     # 读写超时
    lettuce:
      pool:
        max-active: 50
        max-idle: 10
        min-idle: 2
      shutdown-timeout: 100ms

自定义配置类（增强容错）

@Configuration
public class RedisConfig {

    @Bean
    public LettuceClientConfiguration lettuceClientConfiguration() {
        // 启用拓扑刷新（节点变更自动感知）
        ClusterTopologyRefreshOptions topologyRefreshOptions =
            ClusterTopologyRefreshOptions.builder()
                .enablePeriodicRefresh(Duration.ofSeconds(30)) // 每30秒刷新
                .enableAllAdaptiveRefreshTriggers()            // 事件触发刷新
                .adaptiveRefreshTriggersTimeout(Duration.ofSeconds(10))
                .build();

        return LettuceClientConfiguration.builder()
            .commandTimeout(Duration.ofMillis(2000))
            .readFrom(ReadFrom.REPLICA_PREFERRED) // 优先读从节点
            .clientOptions(ClusterClientOptions.builder()
                .topologyRefreshOptions(topologyRefreshOptions)
                .build())
            .build();
    }

    @Bean
    public RedisConnectionFactory redisConnectionFactory(
            LettuceClientConfiguration clientConfig) {
        List<RedisNode> nodes = Arrays.asList(
            new RedisNode("10.0.1.10", 7000),
            new RedisNode("10.0.1.11", 7000),
            // ... 其他节点
        );
        RedisClusterConfiguration clusterConfig = new RedisClusterConfiguration(nodes);
        return new LettuceConnectionFactory(clusterConfig, clientConfig);
    }
}

✅ 关键点：

• enablePeriodicRefresh：定期拉取集群拓扑
• ReadFrom.REPLICA_PREFERRED：负载均衡 + 读写分离

---

🛡️ 五、高可用核心策略：不止靠 Redis 自身！

策略 1：客户端熔断与降级（Hystrix / Resilience4j）

当 Redis 宕机，避免线程池耗尽，直接降级读 DB。

@Service
public class CacheService {

    private final CircuitBreaker circuitBreaker = CircuitBreaker.ofDefaults("redis");

    public String getValue(String key) {
        Supplier<String> decorated = CircuitBreaker
            .decorateSupplier(circuitBreaker, () -> redisTemplate.opsForValue().get(key));

        return Try.ofSupplier(decorated)
            .recover(throwable -> {
                log.warn("Redis 不可用，降级读 DB", throwable);
                return loadFromDatabase(key); // 回源
            })
            .get();
    }
}

🔗 Resilience4j 官网

---

策略 2：多级缓存（Local + Redis）

减少对 Redis 的依赖，提升性能与可用性。

@Cacheable(value = "user", key = "#id", cacheManager = "caffeineRedisCacheManager")
public User getUser(Long id) {
    return userMapper.selectById(id);
}

• 一级缓存：Caffeine（本地，微秒级）
• 二级缓存：Redis（分布式，毫秒级）

即使 Redis 宕机，热点数据仍可从本地缓存获取。

---

策略 3：缓存空值防穿透

防止恶意攻击导致 DB 压垮。

public User getUser(Long id) {
    String key = "user:" + id;
    User user = redisTemplate.opsForValue().get(key);
    
    if (user == null) {
        // 查询 DB
        user = userMapper.selectById(id);
        if (user != null) {
            redisTemplate.opsForValue().set(key, user, Duration.ofMinutes(10));
        } else {
            // 缓存空值，TTL 较短
            redisTemplate.opsForValue().set(key, "", Duration.ofSeconds(60));
        }
    }
    return user == null || "".equals(user) ? null : user;
}

---

📊 六、监控与告警：让问题无处藏身 👁️

必监控指标

类别	指标	告警阈值
可用性	cluster_state	fail → 立即告警
性能	instantaneous_ops_per_sec	突降 50% → 检查
内存	used_memory_rss / maxmemory	> 85% → 扩容预警
客户端	connected_clients	> 10000 → 检查连接泄漏
淘汰	evicted_keys	突增 → 内存不足

集成 Prometheus + Grafana

# prometheus.yml
scrape_configs:
  - job_name: 'redis'
    static_configs:
      - targets: ['10.0.1.10:9121']  # redis_exporter 地址

🔗 Redis Exporter GitHub
🔗 Grafana Redis Dashboard

---

🧭 七、容灾演练：你的系统真的高可用吗？🧪

演练清单

1. 模拟 Master 宕机

   kill -9 $(pgrep redis-server)
   

   → 观察是否在 30 秒内完成 Failover

2. 模拟网络分区（脑裂）

   iptables -A OUTPUT -p tcp --dport 7000 -j DROP
   

   → 检查是否多数派存活，少数派拒绝写入

3. 模拟 Redis OOM
   关闭 maxmemory，写入大量数据
   → 观察是否被系统 kill，监控是否告警

4. 模拟客户端连接风暴
   使用 redis-benchmark 压测
   → 检查连接池是否耗尽，服务是否降级

💡 原则：故障不是会不会发生，而是何时发生。提前演练，才能从容应对。

---

📈 八、高可用缓存系统架构全景图（Mermaid）

---

✅ 九、生产环境 8 条最佳实践清单

1. 必须设置 maxmemory + 合理淘汰策略

   maxmemory 16gb
   maxmemory-policy allkeys-lru
   

2. 禁用危险命令

   rename-command FLUSHALL ""
   rename-command KEYS ""
   

3. 开启 AOF + RDB 混合持久化（Redis 4.0+）

   appendonly yes
   aof-use-rdb-preamble yes
   

4. 客户端必须配置超时与重试

   • connectTimeout: 1~2s
   • socketTimeout: 2~5s

5. 读写分离：读请求走 Replica

   • 减轻 Master 压力
   • 提升读吞吐

6. 关键业务缓存设置较长 TTL + 主动刷新

   • 避免集中失效（雪崩）

7. 定期执行 redis-cli --cluster check

   • 提前发现槽位异常

8. 建立缓存 SLA：命中率 ≥ 95%，P99 延迟 < 5ms

---

🔗 十、权威参考资料（均可正常访问）

• Redis 官方高可用指南
• Redis Cluster 教程
• Lettuce 客户端文档
• Resilience4j 容错库
• Redis Exporter 监控方案

---

💎 结语

设计一个高可用的 Redis 缓存系统，技术只是基础，思维才是关键。你需要同时考虑：

• 架构层面：选型是否匹配业务规模？
• 代码层面：客户端是否具备容错能力？
• 运维层面：监控告警是否覆盖所有风险点？
• 应急层面：故障发生时是否有预案？

记住：高可用不是一劳永逸的配置，而是一套持续演进的工程体系。

愿你的缓存系统，在流量洪峰中稳如泰山，在故障风暴中岿然不动！🚀✨

---

🙌 感谢你读到这里！
🔍 技术之路没有捷径，但每一次阅读、思考和实践，都在悄悄拉近你与目标的距离。
💡 如果本文对你有帮助，不妨 👍 点赞、📌 收藏、📤 分享 给更多需要的朋友！
💬 欢迎在评论区留下你的想法、疑问或建议，我会一一回复，我们一起交流、共同成长 🌿
🔔 关注我，不错过下一篇干货！我们下期再见！✨