1. 课程导论与背景：什么是热点Key、什么是削峰、为什么需要Redis和Kafka协同削峰
1.1 热点Key：系统性能的“隐形杀手”
在分布式系统中，热点Key 是指在一段时间内，某个或某几个缓存Key被极高频率地并发访问，导致单个缓存节点或数据库实例承受远超其设计容量的请求压力。这种现象在电商秒杀、社交大V动态、热点新闻等场景中尤为常见。
典型场景案例： 某电商平台“双11”秒杀活动中，一个商品ID为“SKU-888888”的库存Key在1秒内被超过50万次请求同时读取，导致该Key所在的Redis分片CPU飙升至100%，请求超时率高达60%。
热点Key的危害具有明显的级联效应：
- 缓存节点过载： 单节点CPU/带宽被打满，响应延迟从毫秒级飙升到秒级。
- 缓存击穿： 热点Key过期瞬间，大量请求穿透到后端数据库，引发数据库连接池耗尽。
- 服务雪崩： 数据库响应变慢后，上游服务线程池阻塞，最终导致整个微服务集群不可用。
| 热点Key类型 | 典型特征 | QPS阈值参考 | 常见业务场景 |
|---|---|---|---|
| 读热点 | 大量并发读取同一个Key | > 10万 QPS | 秒杀商品详情、热搜榜单 |
| 写热点 | 大量并发写入同一个Key | > 5万 QPS | 库存扣减、点赞计数器 |
| 读写混合热点 | 读写操作集中在少数Key上 | > 8万 QPS | 大V动态评论、实时投票 |
1.2 削峰：流量治理的核心手段
削峰（Peak Clipping）是指通过技术手段，将突发的、超出系统处理能力的流量高峰进行“削平”处理，使流量以更平滑、更可控的速率进入后端服务，从而保护系统不被瞬时洪峰冲垮。
削峰的核心思想是“先接纳，再处理”，而不是“直接拒绝”。常见的削峰策略包括：
- 请求排队： 将瞬时请求放入队列，后端按固定速率消费。
- 流量整形： 使用令牌桶或漏桶算法限制请求速率。
- 分层过滤： 在网关层、缓存层、应用层逐级过滤无效请求。
- 异步化： 将同步写操作转为异步消息，降低瞬时写入压力。
削峰的关键指标： 削峰率 = (原始峰值QPS - 削峰后峰值QPS) / 原始峰值QPS。企业级系统通常要求削峰率达到80%以上，即10万QPS的洪峰经过削峰后，后端实际接收不超过2万QPS。
1.3 为什么需要Redis和Kafka协同削峰？
单一组件无法完美解决热点Key削峰问题。Redis擅长高速缓存与计数，但面对极端热点时自身会成为瓶颈；Kafka擅长消息缓冲与异步解耦，但无法直接处理高频读请求。两者协同，才能构建完整的削峰体系。
常见误区： 很多团队试图只用Redis的“本地缓存+分布式缓存”双层架构来应对热点，但忽略了写热点场景下Redis单节点写入瓶颈。同样，只用Kafka做全量请求缓冲，会导致消息积压严重，读请求延迟不可控。
Redis与Kafka协同削峰的核心分工如下：
| 组件 | 核心职责 | 削峰场景 | 典型能力 |
|---|---|---|---|
| Redis | 读热点缓存、本地计数、限流令牌 | 读热点削峰、写热点前置过滤 | 毫秒级响应、原子计数、过期淘汰 |
| Kafka | 写请求缓冲、异步持久化、流量整形 | 写热点削峰、数据库写入保护 | 百万级吞吐、消息持久化、消费回溯 |
| 协同价值 | 读走Redis、写走Kafka、最终一致 | 读写混合热点全链路保护 | 削峰率 > 90%、系统可用性 99.99% |
下图展示了Redis与Kafka协同削峰的整体架构：
1.4 协同削峰的核心优势
Redis与Kafka协同并非简单的功能叠加，而是形成了“读-写分离、同步-异步分层”的架构范式：
- 读热点由Redis扛： 利用Redis的极致性能（单节点可达10万+ QPS）直接响应读请求，避免请求进入后端队列造成延迟。
- 写热点由Kafka缓冲： 写请求先进入Kafka，由消费者按可控速率写入数据库，避免数据库写入风暴。
- 流量整形与熔断： 在Redis层实现令牌桶限流，超出阈值的请求直接降级或返回兜底数据；Kafka侧通过消费速率控制实现背压。
- 最终一致性保障： 读请求从Redis获取可能“稍旧”的数据，写请求通过Kafka异步保证最终写入数据库，满足大部分业务场景的可用性要求。
企业级实践数据： 某头部电商平台采用Redis+Kafka协同削峰架构后，秒杀场景下系统可用性从99.9%提升至99.995%，数据库写入压力降低85%，热点Key导致的缓存击穿事件减少90%以上。