1. 课程导论：缓存穿透、击穿、雪崩与 gRPC 故障排查

在分布式系统与微服务架构中，Redis 作为高性能缓存层，与 gRPC 作为高效 RPC 通信框架，是保障系统低延迟、高吞吐的核心组件。然而，缓存层的异常（穿透、击穿、雪崩）与 gRPC 接口的故障（超时、熔断、负载不均）是 SRE 日常运维中最常见的“隐形杀手”。本章将系统梳理这些核心概念，建立统一的故障排查思维模型。

📌 核心目标： 理解三类缓存异常的触发条件与危害，掌握 gRPC 故障的典型表现与排查路径，为后续章节的实战演练打下理论基础。

1.1 缓存穿透、击穿、雪崩：概念与对比

这三类异常虽然都表现为“请求绕过缓存直达数据库”，但触发场景与影响范围截然不同。下表从定义、触发条件、影响范围、典型场景四个维度进行对比：

异常类型 定义 触发条件 影响范围 典型场景
缓存穿透 请求查询一个根本不存在的数据，缓存与数据库均无命中，每次请求都穿透到 DB。 恶意攻击（如遍历不存在的 ID）、业务逻辑漏洞（如查询已删除的数据）。 全局性：所有不存在的 key 都会触发 DB 查询。 刷单攻击、爬虫遍历不存在的商品 ID。
缓存击穿 一个热点 key 在缓存失效的瞬间，大量并发请求同时穿透到 DB。 热点 key 过期 + 高并发访问。 局部性：仅影响单个热点 key。 秒杀商品详情页、微博热搜词条。
缓存雪崩 大量 key 在同一时间或短时间内集中过期，导致请求全部落到 DB。 缓存设置相同的过期时间、Redis 实例宕机、缓存服务重启。 全局性：大面积缓存失效，DB 瞬间压力激增。 双十一零点大量商品缓存同时过期、Redis 集群故障。
💡 记忆口诀： 穿透是“查无此人”，击穿是“一人倒下万人踩”，雪崩是“集体阵亡”。

1.2 三类异常的排查思路与应对策略

针对不同的异常类型，SRE 需要采取差异化的排查与防御手段。以下为实战中常用的策略清单：

  • 缓存穿透：
    • 排查： 监控 DB 查询 QPS 与缓存命中率，分析请求日志中不存在的 key 分布。
    • 应对： 布隆过滤器（Bloom Filter）前置拦截、缓存空对象（设置较短 TTL）、参数校验增强。
  • 缓存击穿：
    • 排查： 定位热点 key，观察其过期时间点前后的 DB 负载与响应延迟。
    • 应对： 互斥锁（Mutex Key）保证单线程重建缓存、逻辑过期（不设置物理 TTL）、热点 key 永不过期 + 后台异步更新。
  • 缓存雪崩：
    • 排查： 检查 Redis 内存使用率、key 过期时间分布、DB 连接池与慢查询日志。
    • 应对： 过期时间添加随机偏移量、多级缓存（本地缓存 + Redis）、Redis 高可用架构（哨兵/集群）、限流降级。
缓存三类异常触发流程对比 正常请求 缓存命中 → 返回 穿透：查不存在 key 缓存未命中 DB 查询（无结果） 击穿：热点 key 过期 高并发同时未命中 DB 瞬间高负载 雪崩：大量 key 过期 缓存大面积失效 DB 被打垮 关键区别总结 • 穿透：数据本身不存在，缓存永远无法命中（布隆过滤器可拦截）。 • 击穿：数据存在，但热点 key 过期瞬间被高并发打穿（互斥锁/逻辑过期可解决）。 • 雪崩：大量 key 同时过期，导致 DB 整体压力暴增（随机 TTL + 多级缓存可缓解）。

1.3 gRPC 接口故障的典型表现

gRPC 基于 HTTP/2 与 Protobuf，在微服务间通信中广泛使用。其故障表现与传统的 RESTful 接口有显著差异，SRE 需要关注以下典型场景：

  • 连接超时（DeadlineExceeded）： 客户端设置的 deadline 内未收到响应，通常由网络抖动、服务端处理过慢、连接池耗尽引起。
  • 服务不可用（Unavailable）： 目标服务未启动、负载均衡器无健康后端、gRPC 服务注册/发现失败。
  • 资源耗尽（ResourceExhausted）： 服务端并发流数超限、内存/CPU 打满、gRPC 的 max_concurrent_streams 配置过小。
  • 内部错误（Internal）： Protobuf 序列化/反序列化失败、业务逻辑 panic、gRPC 拦截器异常。
  • 熔断与降级： 客户端熔断器（如 Hystrix、Resilience4j）触发，请求被快速失败，避免级联故障。
⚠️ 注意： gRPC 的 HTTP/2 长连接特性使得“连接泄漏”成为常见问题。如果客户端未正确关闭流（Stream），服务端会持续占用内存，最终导致 OOM 或连接数耗尽。

1.4 gRPC 故障排查思路

面对 gRPC 接口故障，建议遵循“由外到内、分层排查”的原则。以下为标准化排查流程：

  1. 检查网络层： 使用 ping、traceroute、ss -tlnp 确认网络连通性与端口监听状态。
  2. 检查服务发现： 确认 gRPC 目标地址在注册中心（如 Consul、etcd、K8s Service）中是否健康。
  3. 检查客户端配置： 核对 deadline、max_retries、load_balancing_policy 等参数是否合理。
  4. 检查服务端指标： 查看 gRPC 内置的 grpc_server_handling_seconds、grpc_server_started_total、grpc_server_msg_received_total 等 Prometheus 指标。
  5. 检查日志与链路追踪： 结合结构化日志（如 JSON 格式）与分布式追踪（如 Jaeger、Zipkin）定位慢调用或异常调用链。
  6. 检查熔断与限流： 确认客户端熔断器状态（OPEN/HALF_OPEN/CLOSED），服务端是否触发了限流（如 rate limiter）。
gRPC 故障排查分层模型 第1层：网络层（连通性、延迟、丢包） 第2层：服务发现层（注册中心、健康检查） 第3层：客户端配置层（Deadline、重试、负载均衡） 第4层：服务端指标层（延迟、QPS、错误码、资源使用）

1.5 本章小结

← 上一章 📖 返回目录 下一章 →