我们都知道，提高系统性能的最简单也最流行的方法之一其实就是使用缓存。我们引入缓存，相当于对数据进行了复制。每当系统数据更新时，保持缓存和数据源（如 MySQL 数据库）同步至关重要，当然，这也取决于系统本身的要求，看系统是否允许一定的数据延迟。
最常见的几种缓存策略分别是：
- Cache-Aside（旁路缓存模式）
- Read/Write Through Pattern（读写穿透）
- Write-Behind（异步缓存写入）
这3 种缓存读写策略各有优劣，不存在最佳，需要我们根据具体的业务场景选择更适合的。
Cache Aside Pattern（旁路缓存模式）
Cache Aside Pattern 是我们平时使用比较多的一个缓存读写模式，比较适合读请求比较多的场景。
在这种策略下，应用程序(Application)会与缓存(Cache)和数据源(Data Source)进行通信，应用程序会在命中数据源之前先检查缓存。
请求数据的过程：
- 首先，应用程序先确定数据是否保留在缓存中；
- 如果数据在缓存中，也即 Cache hit ，称作“缓存命中”。数据直接从缓存中读取并返回给客户端应用程序；
- 如果数据不在缓存中，也即 Cache miss，称作“缓存未命中”。应用程序会从数据存储的地方，如 MySQL 数据源中读取该数据，并将数据存储在缓存中，然后将其返回给客户端。
缓存读写步骤:
写 ：
- 先更新 DB
- 然后直接删除 cache 。
读 :
- 从 cache 中读取数据，读取到就直接返回
- cache中读取不到的话，就从 DB 中读取数据返回
- 再把数据放到 cache 中。
Cache-Aside策略特别适合“读多”的应用场景。使用Cache Aside策略的系统可以在一定程度上抵抗缓存故障。如果缓存服务发生故障，系统仍然可以通过直接访问数据库进行操作。
然而，这种策略并不能保证数据存储和缓存之间的一致性，需要配合使用其它策略来更新或使缓存无效。另外，首次请求数据时，总是会导致缓存未命中，这种情况下需要额外的时间来将数据加载到缓存中。为了解决这个问题，开发人员可以通过手动触发查询操作来对数据进行“预热”。
Read/Write Through Pattern（读写穿透）
在上面的Cache-Aside策略中，应用程序需要与缓存和数据源“打交道”，而在Read/Write Through Pattern 策略下，应用程序无需管理数据源和缓存，只需要将数据源的同步委托给缓存提供程序Cache Provider即可。所有数据交互都是通过抽象缓存层完成的。
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 一样，对于热点数据可以提前放入缓存中。
Write Behind Pattern（异步缓存写入）
Write Behind Pattern 和 Read/Write Through Pattern 很相似，两者都是由 cache 服务来负责 cache 和 DB 的读写。
但是，两个又有很大的不同：Read/Write Through 是同步更新 cache 和 DB，而 Write Behind Caching 则是只更新缓存，不直接更新 DB，而是改为异步批量的方式来更新 DB。
很明显，这种方式对数据一致性带来了更大的挑战，比如cache数据可能还没异步更新DB的话，cache服务可能就就挂掉了。
这种策略在我们平时开发过程中也非常非常少见，但是不代表它的应用场景少，比如消息队列中消息的异步写入磁盘、MySQL 的 InnoDB Buffer Pool 机制都用到了这种策略。
Write Behind Pattern 下 DB 的写性能非常高，非常适合一些数据经常变化又对数据一致性要求没那么高的场景，比如浏览量、点赞量。