1. 课程导入与缓存体系全景

当业务从“能用”走向“高并发”，系统瓶颈往往不在业务代码本身，而在数据访问路径。以一次典型商品详情页请求为例：假设日活 300 万，晚高峰 QPS 约 8000，其中 70% 是读请求，即约 5600 QPS 落在读路径上。若这些请求全部打到 MySQL，单条查询按 3ms 计算，仅数据库层就需要约 16.8 个并发连接持续工作，而真实场景中还有事务锁、连接池上限、慢查询和主从延迟，实际承载能力会迅速下降。此时数据库 CPU 飙到 90% 以上、响应时间从 20ms 涨到 800ms，就是典型的“读放大”压垮存储层。

Redis 在这个位置承担的角色，不是“数据库的替代品”，而是位于应用与数据库之间的高速数据层。它把热点数据放在内存中，用 O(1) 或 O(log N) 的访问复杂度承接高频读，把原本压向 MySQL 的流量拦截在缓存层。一个设计良好的缓存体系，通常能把 90% 以上的读请求挡在数据库之前，使数据库只处理缓存未命中和写请求。

为了看清 Redis 在整个系统中的位置，先建立一张分层视图。下图展示了从客户端到数据库的完整数据访问链路，以及 Redis 在其中的拦截点、典型数据形态和关键风险。

这张图给出了本课程的整体坐标系：左侧是流量入口，中间是应用与 Redis，右侧是数据库。真正需要设计的，是“请求在什么条件下走缓存、什么条件下回源、回源后如何写回、缓存失效时如何保护数据库”。这四件事决定了缓存体系是否可靠。

课程目标与学习路径

本课程围绕“能落地”展开，最终目标是让读者能够独立设计并实现一套支撑高并发业务的 Redis 缓存体系。具体包括：能根据业务读写比和一致性要求选择缓存模式；能正确实现缓存读写、更新与失效逻辑；能识别并处理穿透、击穿、雪崩、热点 Key；能完成 Redis 部署形态选型（单机、主从、哨兵、集群）；能配置合理的过期、淘汰与持久化策略；能通过监控指标判断缓存健康度并定位问题。

学习路径按“认知 → 单机 → 高可用 → 高并发 → 治理”推进。前几章先建立缓存体系全景与 Redis 数据模型认知；随后进入缓存读写模式、Key 设计与过期策略；再展开主从复制、哨兵与 Cluster 分片；之后集中处理一致性、穿透击穿雪崩、热点 Key、分布式锁与限流；最后落到监控、容量规划与故障复盘。每一章都会给出可执行的配置、命令或代码片段，而不是停留在概念层。

最后需要明确一个判断标准：缓存体系的好坏，不取决于 Redis 用得多复杂，而取决于数据库是否被有效保护，以及数据是否在可接受范围内保持一致。后续所有设计，都围绕这两个目标展开。