系统设计-缓存介绍

该图说明了我们在典型架构中缓存数据的位置。

沿着流程有多个层次。

1. 客户端应用程序：HTTP 响应可以由浏览器缓存。我们第一次通过 HTTP 请求数据，返回时在 HTTP 标头中包含过期策略；我们再次请求数据，客户端应用程序首先尝试从浏览器缓存中检索数据。
2. CDN：CDN缓存静态网页资源。客户端可以从附近的CDN节点检索数据。
3. 负载均衡器：负载均衡器也可以缓存资源。
4. 消息传递基础设施：消息代理首先将消息存储在磁盘上，然后消费者按照自己的节奏检索消息。根据保留策略，数据会在Kafka集群中缓存一段时间。
5. 服务：服务中有多层缓存。如果数据没有缓存在CPU缓存中，服务将尝试从内存中检索数据。有时服务有二级缓存来将数据存储在磁盘上。
6. 分布式缓存：像Redis这样的分布式缓存在内存中保存多个服务的键值对。它提供比数据库更好的读/写性能。
7. 全文搜索：我们有时需要使用全文搜索，例如Elastic Search来进行文档搜索或日志搜索。数据副本也会在搜索引擎中建立索引。
8. 数据库：即使在数据库中，我们也有不同级别的缓存：

• WAL(Write-ahead Log)：在构建B树索引之前，先将数据写入WAL
• Bufferpool：分配用于缓存查询结果的内存区域
• 物化视图：预先计算查询结果并将其存储在数据库表中以获得更好的查询性能
• 事务日志：记录所有事务和数据库更新
• 复制日志：用于记录数据库集群中的复制状态

 为什么Redis这么快？

1. Redis 是一个基于 RAM 的数据存储。RAM 访问至少比随机磁盘访问快 1000 倍。
2. Redis 利用 IO 多路复用和单线程执行循环来提高执行效率。
3. 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:

• 工作原理： 写操作直接更新缓存，并且同步更新到数据源，确保数据一致性。

• 适用场景：

  • 需要强一致性的场景，对实时性要求较高。
  • 适用于事务性应用，要求写入后立即生效。

比较与选择：

• 不同的缓存模式适用于不同的应用场景，选择应根据应用程序的读写模式、数据变更频率以及对实时性和一致性的需求进行权衡。