缓存读写是指在使用缓存技术时，对数据进行读取和更新的操作过程。缓存是一种用于提高系统性能和可扩展性的技术，通过减少对慢速存储（如数据库）的访问次数，降低网络延迟，从而提升用户体验。
一、缓存读操作
缓存读操作是指从缓存中读取数据的过程。当应用程序需要读取数据时，会首先尝试从缓存中获取。如果缓存中存在所需的数据（称为缓存命中），则直接返回该数据给应用程序，无需再去访问慢速存储。如果缓存中不存在所需的数据（称为缓存未命中），则需要从慢速存储（如数据库）中读取数据，然后将数据放入缓存中，并返回给应用程序。
二、缓存写操作
缓存写操作是指将数据写入缓存的过程。写操作相对复杂一些，因为需要考虑数据的一致性和可靠性。常见的缓存写策略包括：
- 旁路缓存（Cache Aside Pattern）：在这种模式下，应用程序直接操作数据库和缓存。当需要更新数据时，应用程序会首先更新数据库，然后删除或更新缓存中的对应数据。这种模式适用于数据一致性要求较高的场景。
- 直读直写模式（Read/Write Through）：在这种模式下，缓存替应用程序与数据库进行交互。对于读请求，如果缓存命中，则直接返回数据；如果缓存未命中，则缓存会从数据库中读取数据，并存放到缓存中后返回。对于写请求，如果缓存命中，则缓存会更新数据，并同步更新数据库；如果缓存未命中，则应用程序会直接更新数据库。这种模式简化了应用程序的代码，但增加了缓存和数据库之间的交互复杂性。
- 写回模式（Write-Back）：在这种模式下，写操作不会立即更新数据库，而是先将数据写入缓存，并标记为脏数据。当缓存需要被替换或定时更新时，再将脏数据写回数据库。这种模式可以提高写操作的性能，但增加了数据丢失的风险，因为脏数据在写回数据库之前可能会因为系统故障而丢失。
下面介绍到的三种模式各有优劣，不存在最佳模式，根据具体的业务场景选择适合自己的缓存读写模式
Cache Aside Pattern（旁路缓存模式）
Cache Aside Pattern 是我们平时使用比较多的一个缓存读写模式，比较适合读请求比较多的场景。
Cache Aside Pattern 中服务端需要同时维系 db 和 cache，并且是以 db 的结果为准。
下面我们来看一下这个策略模式下的缓存读写步骤。
写：
- 先更新 db
- 然后直接删除 cache 。
简单画了一张图帮助大家理解写的步骤。
读 :
- 从 cache 中读取数据，读取到就直接返回
- cache 中读取不到的话，就从 db 中读取数据返回
- 再把数据放到 cache 中。
简单画了一张图帮助大家理解读的步骤。
你仅仅了解了上面这些内容的话是远远不够的，我们还要搞懂其中的原理。
比如说别人很可能会问你：“在写数据的过程中，可以先删除 cache ，后更新 db 么？”
答案： 那肯定是不行的！因为这样可能会造成 数据库（db）和缓存（Cache）数据不一致的问题。
举例：请求 1 先写数据 A，请求 2 随后读数据 A 的话，就很有可能产生数据不一致性的问题。
这个过程可以简单描述为：
请求 1 先把 cache 中的 A 数据删除 -> 请求 2 从 db 中读取数据->请求 1 再把 db 中的 A 数据更新
当你这样回答之后，可能会紧接着就追问：“在写数据的过程中，先更新 db，后删除 cache 就没有问题了么？”
答案： 理论上来说还是可能会出现数据不一致性的问题，不过概率非常小，因为缓存的写入速度是比数据库的写入速度快很多。
举例：请求 1 先读数据 A，请求 2 随后写数据 A，并且数据 A 在请求 1 请求之前不在缓存中的话，也有可能产生数据不一致性的问题。
这个过程可以简单描述为：
请求 1 从 db 读数据 A-> 请求 2 更新 db 中的数据 A（此时缓存中无数据 A ，故不用执行删除缓存操作 ） -> 请求 1 将数据 A 写入 cache
现在我们再来分析一下 Cache Aside Pattern 的缺陷。
缺陷 1：首次请求数据一定不在 cache 的问题
解决办法：可以将热点数据可以提前放入 cache 中。
缺陷 2：写操作比较频繁的话导致 cache 中的数据会被频繁被删除，这样会影响缓存命中率 。
解决办法：
- 数据库和缓存数据强一致场景：更新 db 的时候同样更新 cache，不过我们需要加一个锁/分布式锁来保证更新 cache 的时候不存在线程安全问题。
- 可以短暂地允许数据库和缓存数据不一致的场景：更新 db 的时候同样更新 cache，但是给缓存加一个比较短的过期时间，这样的话就可以保证即使数据不一致的话影响也比较小。
Read/Write Through Pattern（读写穿透）
Read/Write Through Pattern 中服务端把 cache 视为主要数据存储，从中读取数据并将数据写入其中。cache 服务负责将此数据读取和写入 db，从而减轻了应用程序的职责。
这种缓存读写策略小伙伴们应该也发现了在平时在开发过程中非常少见。抛去性能方面的影响，大概率是因为我们经常使用的分布式缓存 Redis 并没有提供 cache 将数据写入 db 的功能。
写（Write Through）：
- 先查 cache，cache 中不存在，直接更新 db。
- cache 中存在，则先更新 cache，然后 cache 服务自己更新 db（同步更新 cache 和 db）。
简单画了一张图帮助大家理解写的步骤。
读(Read Through)：
- 从 cache 中读取数据，读取到就直接返回 。
- 读取不到的话，先从 db 加载，写入到 cache 后返回响应。
简单画了一张图帮助大家理解读的步骤。
Read-Through Pattern 实际只是在 Cache-Aside Pattern 之上进行了封装。在 Cache-Aside Pattern 下，发生读请求的时候，如果 cache 中不存在对应的数据，是由客户端自己负责把数据写入 cache，而 Read Through Pattern 则是 cache 服务自己来写入缓存的，这对客户端是透明的。
和 Cache Aside Pattern 一样， Read-Through Pattern 也有首次请求数据一定不再 cache 的问题，对于热点数据可以提前放入缓存中。
缓存写入">Write Behind Pattern（异步缓存写入）
Write Behind Pattern 和 Read/Write Through Pattern 很相似，两者都是由 cache 服务来负责 cache 和 db 的读写。
但是，两个又有很大的不同：Read/Write Through 是同步更新 cache 和 db，而 Write Behind 则是只更新缓存，不直接更新 db，而是改为异步批量的方式来更新 db。
很明显，这种方式对数据一致性带来了更大的挑战，比如 cache 数据可能还没异步更新 db 的话，cache 服务可能就就挂掉了。
这种策略在我们平时开发过程中也非常非常少见，但是不代表它的应用场景少，比如消息队列中消息的异步写入磁盘、MySQL 的 Innodb Buffer Pool 机制都用到了这种策略。
Write Behind Pattern 下 db 的写性能非常高，非常适合一些数据经常变化又对数据一致性要求没那么高的场景，比如浏览量、点赞量。
