上一篇
http怎么缓存数据库，http缓存数据库的最佳实践
HTTP 协议本身是无状态的，而数据库通常是持久化存储。“HTTP 缓存数据库”这一说法在技术严谨性上存在偏差，我们通常讨论的是“如何缓存数据库的查询结果，以便通过 HTTP 接口快速响应前端请求”。
这种架构的核心目标是减少数据库的直接读取压力,降低延迟，提高系统吞吐量，以下是实现这一目标的详细策略、技术选型及最佳实践。
核心架构原理
在 Web 应用中，数据流向通常是：前端 -> HTTP 服务器 (Nginx/Node.js/Go等) -> 缓存层 (Redis/Memcached) -> 数据库 (MySQL/PostgreSQL等)。
当用户发起 HTTP 请求时：
- 缓存命中：如果缓存中存在最新数据，直接返回，不经过数据库。
- 缓存未命中：从数据库读取数据，写入缓存，然后返回给前端。
常见的缓存策略
1 旁路缓存策略 (Cache-Aside Pattern)
这是最常用且推荐的方式。
- 读操作：先查缓存，命中则返回；未命中则查数据库，将结果写入缓存，再返回。
- 写操作：先更新数据库，然后删除缓存（而不是更新缓存）。
- 为什么删除而不是更新？ 避免并发写入导致脏数据，如果两个线程同时更新，先更新的线程写入缓存，后更新的线程也写入缓存，可能导致数据不一致，删除缓存后，下次读取时会自动重建最新数据。
2 读写穿透 (Read-Through / Write-Through)
通常由缓存中间件（如 Redis 集群）或应用层封装实现。
- 读操作：应用直接请求缓存，缓存内部负责从数据库加载并返回。
- 写操作：应用直接请求缓存，缓存负责同步写入数据库。
- 优点：应用代码简洁。
- 缺点：耦合度高，缓存组件需具备数据库连接能力。
3 异步更新缓存 (Write-Behind)
- 写操作：应用只更新缓存，数据库的更新由后台异步线程批量完成。
- 优点：写入性能极高。
- 缺点：存在数据丢失风险（宕机时内存数据丢失），一致性较差。
HTTP 层面的缓存控制
除了应用层的缓存,HTTP 协议本身也提供了缓存机制，适用于极少变更的数据（如配置信息、静态资源元数据）。
| 头部字段 | 说明 | 适用场景 |
|---|---|---|
| Cache-Control: max-age=3600 | 指定资源在客户端或代理服务器缓存的有效时间（秒）。 | 静态数据、不常变动的列表。 |
| ETag / If-None-Match | 实体标签，服务器返回资源的唯一标识，客户端下次请求携带此标签，若未变化，服务器返回 304 Not Modified。 | 需要精确控制版本一致性的资源。 |
| Last-Modified / If-Modified-Since | 基于文件最后修改时间进行验证。 | 简单的资源缓存验证。 |
注意：HTTP 缓存主要解决的是网络传输和客户端/代理层的重复请求问题，而应用层缓存（如 Redis）解决的是数据库负载问题，两者结合效果最佳。
技术选型对比
| 缓存组件 | 类型 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| Redis | 内存数据库 | 高性能、支持多种数据结构、持久化、集群方案成熟 | 占用内存较大，需维护集群 | 通用场景，高并发读/写，复杂数据结构 |
| Memcached | 内存键值存储 | 简单、高性能、多核支持好 | 仅支持简单 KV，无持久化，功能单一 | 简单的对象缓存，对数据结构要求低 |
| 本地缓存 (Caffeine/Guava) | JVM 内缓存 | 零网络开销，速度最快 | 数据不一致（多实例间不同步），内存受限 | 热点数据、配置信息、多实例共享数据少 |
常见陷阱与解决方案
1 缓存穿透
- 现象：查询不存在的数据，缓存和数据库都没有，请求直达数据库。
- 解决：
- 缓存空对象（设置较短过期时间）。
- 使用布隆过滤器（Bloom Filter）在请求到达缓存前拦截非法 key。
2 缓存击穿
- 现象：某个热点 key 过期瞬间，大量请求同时打到数据库。
- 解决：
- 设置热点数据永不过期。
- 使用互斥锁（Mutex Lock），只允许一个线程查库并重建缓存，其他线程等待。
3 缓存雪崩
- 现象：大量 key 在同一时间过期，或缓存服务宕机。
- 解决：
- 过期时间添加随机值（如 base_time + random(1-5)）。
- 构建高可用缓存集群（Redis Sentinel/Cluster）。
- 服务降级或限流。
4 数据一致性
- 问题：数据库更新后，缓存未更新或更新延迟，导致短暂不一致。
- 解决：
- 最终一致性：大多数业务可接受秒级延迟，采用“先更库，再删缓存”策略。
- 延迟双删：先删缓存 -> 更库 -> 休眠 N 毫秒 -> 再删缓存（防止并发读写入旧数据）。
- 订阅 Binlog：通过 Canal 等工具监听数据库 Binlog，异步更新或删除缓存，保证高一致性。
实施步骤建议
- 识别热点数据：分析日志，找出 QPS 高、读取频繁但更新少的数据。
- 选择缓存中间件：首选 Redis，因其生态完善。
- 设计缓存 Key：确保 Key 的唯一性和可读性，如 user:info:{id}。
- 实现缓存逻辑：在 Service 层封装缓存读写方法，遵循 Cache-Aside 模式。
- 设置过期时间：根据数据变更频率设置合理的 TTL。
- 监控与告警：监控缓存命中率、延迟、内存使用率。
相关问题与解答
Q1: 如何保证数据库和缓存之间的数据一致性？
A: 保证强一致性非常困难且影响性能，通常追求最终一致性，推荐方案如下：
- 先更新数据库，再删除缓存：这是最基础且常用的策略。
- 延迟双删：在更新数据库前后各删除一次缓存，中间休眠一小段时间（如 500ms），以应对并发读取写入旧数据的情况。
- 基于 Binlog 的异步更新：使用 Canal 或 Debezium 监听 MySQL 的 Binlog，解析出变更数据，发送到消息队列（如 Kafka），再由消费者服务更新或删除缓存，这种方式解耦性好，可靠性高，是目前大型互联网架构的主流方案。
Q2: 缓存穿透、缓存击穿和缓存雪崩有什么区别？如何分别解决？
A:
- 缓存穿透：
- 定义：查询不存在的数据，缓存不命中，数据库也不存在，请求直达数据库。
- 解决：缓存空对象（短 TTL）、使用布隆过滤器拦截非法请求。
- 缓存击穿：
- 定义：某个热点 key 过期瞬间，大量请求同时访问，导致数据库压力骤增。
- 解决：设置热点数据永不过期、使用互斥锁（只让一个线程重建缓存）、逻辑过期（不设置 TTL，在代码中判断是否过期，异步重建）。
- 缓存雪崩：
- 定义：大量 key 在同一时间过期，或缓存服务整体宕机，导致所有请求打到数据库。
- 解决：过期时间加随机值、构建高可用缓存集群、服务降级/限流、设置多级缓存（本地缓存 + 分布式缓存）。
