该图说明了我们在典型架构中缓存数据的位置。
沿着流程有多个层次。
- 客户端应用程序：HTTP 响应可以由浏览器缓存。我们第一次通过 HTTP 请求数据，返回时在 HTTP 标头中包含过期策略；我们再次请求数据，客户端应用程序首先尝试从浏览器缓存中检索数据。
- CDN：CDN缓存静态网页资源。客户端可以从附近的CDN节点检索数据。
- 负载均衡器：负载均衡器也可以缓存资源。
- 消息传递基础设施：消息代理首先将消息存储在磁盘上，然后消费者按照自己的节奏检索消息。根据保留策略，数据会在Kafka集群中缓存一段时间。
- 服务：服务中有多层缓存。如果数据没有缓存在CPU缓存中，服务将尝试从内存中检索数据。有时服务有二级缓存来将数据存储在磁盘上。
- 分布式缓存：像Redis这样的分布式缓存在内存中保存多个服务的键值对。它提供比数据库更好的读/写性能。
- 全文搜索：我们有时需要使用全文搜索，例如Elastic Search来进行文档搜索或日志搜索。数据副本也会在搜索引擎中建立索引。
- 数据库：即使在数据库中，我们也有不同级别的缓存：
- WAL(Write-ahead Log)：在构建B树索引之前，先将数据写入WAL
- Bufferpool：分配用于缓存查询结果的内存区域
- 物化视图：预先计算查询结果并将其存储在数据库表中以获得更好的查询性能
- 事务日志：记录所有事务和数据库更新
- 复制日志：用于记录数据库集群中的复制状态
为什么Redis这么快？
- Redis 是一个基于 RAM 的数据存储。RAM 访问至少比随机磁盘访问快 1000 倍。
- Redis 利用 IO 多路复用和单线程执行循环来提高执行效率。
- Redis 利用多种高效的低级数据结构。
如何使用Redis
Redis 使用场景
Redis 可用于多种场景，如图所示。
会话
我们可以使用Redis在不同服务之间共享用户会话数据。
缓存
我们可以使用Redis来缓存对象或页面，尤其是热点数据。
分布式锁
我们可以使用Redis字符串来获取分布式服务之间的锁。
统计
我们可以统计文章的点赞数或阅读量。
速率限制器
我们可以对某些用户 IP 应用速率限制器。
全局 ID 生成器
我们可以使用 Redis Int 作为全局 ID。
购物车
我们可以使用 Redis Hash 来表示购物车中的键值对。
计算用户保留率
我们可以使用Bitmap来表示每天的用户登录情况并计算用户留存情况。
消息队列
我们可以使用 List 作为消息队列。
排行
我们可以使用ZSet对文章进行排序。
顶级缓存策略
设计大型系统通常需要仔细考虑缓存。以下是五种常用的缓存策略。
1. Cache Aside (Lazy-Load):
工作原理： 应用程序负责直接读写缓存。数据在被读取时，首先尝试从缓存获取；在写入时，直接更新缓存，并且可能在后续异步或同步地更新数据源。
适用场景：
- 读密集型工作负载。
- 数据变更不频繁的情况。
- 实时性要求不高的应用。
2. Read Through:
工作原理： 缓存系统管理缓存，并在数据未命中时从数据源（通常是数据库）读取数据。应用程序直接访问缓存，而缓存负责从数据源读取数据。
适用场景：
- 读操作频繁，对实时性要求较高。
- 数据源对应用程序相对透明。
3. Write-Around:
工作原理： 写操作直接更新数据源，而不是直接更新缓存。只有被读取的数据才会放入缓存。
适用场景：
- 写操作频繁，但读操作相对较少。
- 数据变更频繁，但不是立即被读取的情况。
4. Write-Back (Write-Behind):
工作原理： 写操作首先更新缓存，然后异步地或在特定条件下将缓存中的数据批量写回到数据源。
适用场景：
- 写操作频繁，对实时性要求相对较低。
- 提高写操作性能，通过批量写回减少对数据源的频繁写入。
5. Write Through:
工作原理： 写操作直接更新缓存，并且同步更新到数据源，确保数据一致性。
适用场景：
- 需要强一致性的场景，对实时性要求较高。
- 适用于事务性应用，要求写入后立即生效。
比较与选择：
- 不同的缓存模式适用于不同的应用场景，选择应根据应用程序的读写模式、数据变更频率以及对实时性和一致性的需求进行权衡。