缓存层场景实战
个人水平有限，可能有错，欢迎大家在评论区指正和讨论。
这是我读完王伟杰《从程序员到架构师》的读书笔记。这只是一个总结，真正深入学习，还是推荐读书！
文章目录
- 《从程序员到架构师》第二部分「缓存层场景实战」
- 第 4 章 读缓存
- 核心业务痛点
- 核心内容
- 小结
- 第 5 章 写缓存
- 核心业务痛点
- 核心内容
- 小结
- 第 6 章 数据收集
- 核心业务痛点
- 核心内容
- 小结
- 第 7 章 秒杀架构
- 核心业务痛点
- 整体分层解决思路（层层拦截流量，越上层拦截成本越低）
- 小结
- 第二部分整体总结
《从程序员到架构师》第二部分「缓存层场景实战」
第 4 章 读缓存
核心业务痛点
电商商品详情页逻辑复杂，一次请求执行数十条 SQL，页面加载十几秒，用户体验极差；本地内存缓存硬件成本过高不可行。解决读请求量大、查询耗时十几秒问题。
核心内容
中间件选型：对比 Memcached、MongoDB、Redis，从数据结构、持久化、集群能力三个维度论证 Redis 更适合业务缓存场景。
缓存存取策略：标准「先查缓存，无数据再查库回写」流程，详细拆解三大缓存问题：
缓存击穿：热点 Key 失效并发查库，采用分布式锁控制；
缓存雪崩：大批量 Key 同时过期，设置随机过期时间；
缓存穿透：非法不存在的 ID 频繁打库，空值缓存、参数双层校验两种方案。
缓存更新方案：先更数据库、再删除缓存（延迟双删）
缓存高可用：Redis 集群设计要点，负载均衡、分片、数据冗余、故障自动转移、一致性保障五大核心设计。
缓存监控：监控核心指标（命中率、内存、慢查询、连接数）与主流开源监控工具。
小结
读缓存核心作用：分摊数据库查询压力，将十几秒查询压缩至毫秒级；短板是仅解决读压力，无法应对短时海量写请求。
第 5 章 写缓存
核心业务痛点
限时预约活动短时间涌入数十万写入请求，数据库 TPS 上限不足以承载瞬时洪峰，重构分库分表成本太高，需要低成本临时方案。解决短期高频写入冲击数据库。
核心内容
写缓存核心思想：写入请求先落地高性能缓存层异步批量落库，利用缓存高吞吐削峰，匀速将数据写入数据库，隔离流量峰值。
落地实现思路
同步 / 异步两种写入模式对比，业务选用异步方案，配套前端页面延迟提示；
双重触发机制：达到指定条数批量写入 + 定时周期批量写入，避免数据长期滞留缓存；
存储选择 Redis，分析本地内存宕机丢数缺陷；
批量处理并发控制：单线程批量落库规避数据库并发锁竞争；
异常处理：落库失败自动重试，依靠 Redis 持久化保障数据不丢失。
小结
写缓存仅适用于短期临时流量洪峰，无法支撑长期超大写入；不适合存在资源竞争（如库存扣减）的业务场景。
第 6 章 数据收集
核心业务痛点
业务需采集海量用户行为埋点日志，用于数据分析、费用结算，采集流程不能拖慢核心业务接口，同时支持实时多维度查询与定时统计。亿万级埋点日志无侵入采集，不干扰主业务。
核心内容
技术选型全链路拆解
前端埋点数据先落本地日志，避免同步上报拖慢接口；
采集工具：Logstash/Filebeat 读取本地日志；
缓冲中间件 Kafka：利用顺序写入、高吞吐特性承接海量日志；
实时计算引擎 Flink：清洗、补全业务维度数据；
存储分层：ES 用于日志条件检索、HBase 存原始明细、MySQL 存储统计结算数据。
整套完整架构流程：埋点请求→本地日志→采集器→Kafka→Flink 清洗→多路写入 ES/HBase/MySQL。
小结
该架构解决长期海量写入场景，分离日志采集与核心业务，实现日志解耦、海量存储与实时统计；是流量日志、用户埋点标准落地架构。
第 7 章 秒杀架构
核心业务痛点
秒杀瞬间涌入海量用户请求，流量极易打垮网关、服务、数据库，需保证不超卖、订单不丢失、服务不宕机，且改造改动尽可能小。综合缓存、限流、削峰等技术的综合高并发场景。
整体分层解决思路（层层拦截流量，越上层拦截成本越低）
前端 / CDN 层：静态资源放 CDN，页面控制按钮、时间判断，过滤无效刷新请求；
网关层：基于令牌桶限流，拦截绝大多数无效流量，区分机器人与普通用户；
缓存层：商品库存预存入 Redis，通过 decr 原子操作控制库存、防止超卖；
下单写缓存：下单请求先写入 Redis 缓存，MQ 异步批量生成订单、扣库，削峰；
支付环节：超时未付款自动释放库存，保障库存一致性；
全链路高可用：网关、服务、Redis、MQ 全部集群部署，配套熔断兜底。
小结
秒杀是缓存、限流、写削峰、异步消息的综合落地场景，核心思路是流量分层拦截、缓存承载热点、异步落库减轻 DB 压力。
第二部分整体总结
逻辑递进关系
先解决读慢（第 4 章读缓存）→ 再解决瞬时写洪峰（第 5 章写缓存）→ 长期海量日志写入（第 6 章数据收集）→ 融合所有缓存、中间件技术，落地最复杂的秒杀高并发场景（第 7 章）。统一核心思想
所有方案均遵循「把压力从数据库转移到吞吐更高的缓存 / 消息中间件」，通过缓存分担读写、异步削峰，保护核心数据库，实现接口提速、系统稳抗大流量。场景边界区分
读缓存：通用查询优化，适用绝大多数查询业务；
写缓存：仅限短期活动瞬时写高峰；
日志收集：长期海量埋点、大数据分析场景；
秒杀：综合性极端高并发场景，融合前面全部缓存、异步、限流能力。
通用技术栈
核心中间件以 Redis、Kafka、Elasticsearch、Flink 为主，所有方案附带真实业务踩坑点、异常容错、高可用、监控配套完整落地方案，全部来自线上真实项目。