艾体宝洞察 | 在 Redis 之上，聊一聊架构思维

在分布式系统领域深耕多年，我多次亲眼目睹设计不当的系统以足以压垮服务器的方式传输数据。一个反复出现的现象是：Redis一旦出现问题，工程师们便将矛头指向Redis。然而，Redis几乎从不是罪魁祸首，真正的问题在于围绕它构建的架构。

在每一次重大事故的复盘中，包括最近那次影响全球数千项服务的AWS事件，根本原因最终都指向同一点：

崩溃的不是Redis，而是我们对Redis的假设。

本文将深入探讨以下内容：

引发Redis导致系统中断的隐性架构缺陷
围绕Redis构建系统的正确思维模型
区分初级与资深工程师的实战方法
故障示意图与恢复方案
在将问题归因于数据库之前应核查的要点清单

AWS 大面积故障背后，带给我们的是什么？

级联故障的根源在于大量系统默认假设Redis能够始终低延迟响应并能无限地扩展，而这一假设在设计上本就存在缺陷。

Redis作为内存数据存储，擅长处理低延迟的热数据 ，但被误用为主数据库或无限消息队列时极易逼近极限。常见模式是：

应用 -> Redis（单节点）-> 数据库

一旦单节点性能下降，请求排队、线程池耗尽、CPU飙升、超时增加、流量重试，最终导致Redis及全局服务崩溃。问题不在Redis，而在于该架构自身存在单点故障。

正确的架构应该长什么样？

bash 复制代码

┌────────────┐
│   客户端   │
└──────┬─────┘
       │ 请求
       ▼
┌──────────────────────────────┐
│ 应用层（熔断器 / Circuit Breaker）│
└──────┬───────────┬─────────────┘
       │           │
┌──────┘           └──────┐
▼                         ▼
┌──────────────┐    ┌─────────────────┐
│ Redis 主节点 │◄───│ Redis 从节点     │
└──────────────┤    │（读副本）        │
               │    └─────────────────┘
               │ 降级
               ▼
        ┌─────────────────────┐
        │ 真实数据库 / 缓存穿透 │
        └─────────────────────┘

大多数系统中缺失的组件

|-------------------------|---------|
| 组件 | 为什么重要 |
| 熔断器 (Circuit Breaker) | 防止故障雪崩 |
| 读副本 (Read Replicas) | 降低主节点争抢 |
| 本地缓存 (Local Cache) | 减少外部依赖 |
| 降级路径 (Fallback Flow) | 避免用户侧异常 |
| TTL 纪律 (TTL Discipline) | 防止存储爆炸 |
| 限流降级 (Load Shedding) | 抵御重试风暴 |

Redis架构的致命错误

将Redis作为主数据库 ：Redis适用于缓存和临时存储。如果系统无法承受Redis数据丢失，说明架构设计存在问题。
缺乏熔断机制：团队没有实现实现快速失败，而是不断排队请求，直至服务器不堪重负。使用Resilience4j的修复示例：

java 复制代码

// 创建默认配置的熔断器
CircuitBreaker cb = CircuitBreaker.ofDefaults("redisCB");// 用熔断器装饰从Redis获取数据的Supplier
Supplier<String> cachedSupplier = CircuitBreaker
        .decorateSupplier(cb, () -> redisClient.get(键));// 尝试执行，若失败则执行后备方案
String 值 = Try.ofSupplier(cachedSupplier).recover(异常 -> 后备方案获取数据()).get();

Redis中存一切：任何大于10KB的数据都应该三思。应存储ID，而不是整个数据块。
滥用Redis作为消息队列 ：复杂环境下请使用Kafka、SQS或RabbitMQ代替。Redis队列会在重试压力下崩溃。
没有背压或速率限制：如果流量激增，Redis就会成为的瓶颈。
单节点或单可用区部署：如果你只依赖一个Redis端点，那么中断是必然的。
重试风暴：重试会将中断的影响放大数倍。

基准测试

测试：1000万次获Get/Set操作

|----------------|------------------|
| 初级工程师思维 | 资深工程师思维 |
| Redis 能用 → 全靠它 | Redis 会挂 → 先想好预案 |
| 加更多重试 | 加背压和限流降级 |
| 换更大的节点 | 换更聪明的拓扑 |
| 假设最好的情况 | 设计最坏的情况 |
| 修 Redis | 修架构 |

资深工程师的关键：

Redis 能扛住的前提是 负载被分散 、 故障被隔离 、 缓存命中率足够高 。

如何正确使用Redis

架构检查

缓存命中率低？那还不如不用缓存
有降级路径（读从库 / 本地缓存）
每个服务都有独立的熔断器
有分片或复制
TTL 策略严格
避免多键操作
用 Cache-Aside 或 Write-Through 模式

正确的旁路缓存示例

java 复制代码

// 创建默认配置的熔断器
CircuitBreaker cb = CircuitBreaker.ofDefaults("redisCB");// 用熔断器装饰从Redis获取数据的Supplier
Supplier<String> cachedSupplier = CircuitBreaker
        .decorateSupplier(cb, () -> redisClient.get(键));// 尝试执行，若失败则执行后备方案
String 值 = Try.ofSupplier(cachedSupplier).recover(异常 -> 后备方案获取数据()).get();

最后说两句

Redis 没崩。Redis 做了它该做的事。

真正崩的是：

没有护栏的架构
充满魔法假设的设计
没做过演练的系统
没有熔断器的重试风暴

系统的韧性，取决于你的故障应对策略，而不是你的基础设施。

下次出故障，别再说：

"Redis 挂了。"

多问一句：

"为什么我们设计了一个 Redis 慢 400ms 就全线崩溃的系统？"