Redis缓存策略

（1）读不动缓存，写动缓存（读的时候不动缓存，那什么时候动缓存呢，那就是写的时候，对吧）。那我们怎么知道什么时候应该把数据写进去，什么数据应该写进去呢。那就是全量写。就相当于把redis当数据库来用了，要保证写的数据同步到redis中去，这种全量写，一般是不会读数据库的，数据库的压力就会很小，只扛写的压力。

读远大于写的系统，用这种策略能够很好得保护数据库。

这个模式会先去读缓存，没读到，一般也不会去读数据库了，没读到就返回没有。

缺点：

（1）redis内存空间占用大，内存的价格要比硬盘贵。

（2）数据同步要求高，redis中的数据要和mysql中的数据同步。

---

（2）写不动缓存，读动缓存。数据不一致情况比较严重，一般不使用。

---

（3）读写均更新

• Cache-Aside Pattern:旁路缓存模式

读：先去缓存中看看有没有数据，有数据就返回，没有数据的话，就去查数据库，然后把数据放到缓存中。

写：先去更新数据库，然后将缓存中的数据删了，为什么不更新缓存中的数据呢？---》因为更新可能会造成数据库和redis中的数据不一致。但是当数据并发量高的时候，可以使用更新。更新可以有效地利用缓存，删除，再下一次读取的时候，还需要将数据库中的数据读到缓存中。

• Read Through Cache Pattern:读穿透模式

和Cache-Aside差不多，也是先从缓存中获取数据，没有就查数据库，然后放入缓存，区别是，Cache-Aside在于应用服务不再和缓存直接交互，而是先访问数据服务，数据服务自己来根据情况查询缓存或数据库。

• Write Through Cache Pattern:写穿透模式

先查询要写入的数据在缓存中是否存在

存在，就先更新缓存再更新数据库。

不存在，（1）一种策略：先将数据写入缓存，然后由组件同步更新到数据库

（2）另一种策略，直接写入数据库，等读的时候再加载进行。

一般使用Write Through，都搭配Read Through使用。Write Through潜在使用场景是银行系统。

Write Through适用情况有：

（1）需要频繁读取相同数据，

（2）不能忍受数据丢失和数据不一致。

在使用Write Through时要特别注意的是缓存的有效性管理，否则会导致大量的缓存占用内存资源。甚至有效缓存数据会被无效的缓存数据给清除掉。

• Write Behind Pattern: 又叫Write Back，异步缓存写入模式

Write Behind也是先写缓存，再写数据库。只不过是异步的。Write-Through是马上写数据库。

Write-Behind和Write-Through在"程序只和缓存交互且只能通过缓存写数据"这方面很相似。不同点在于Write-Through会把数据立即写入数据库中，而Write-Behind会在一段时间之后(或是被其他方式触发）把数据一起写入数据库，这个异步写操作是Write-Behind的最大特点。

数据库写操作可以用不同的方式完成，其中一个方式就是收集所有的写操作并在某一时间点（比如数据库负载低的时候）批量写入。另一种方式就是合并几个写操作成为一个小批次操作，接着缓存收集写操作一起批量写入。

异步写操作极大地降低了请求延迟并减轻了数据库的负担。同时也放大了数据不一致的。比如有人此时直接从数据库中查询数据，但是更新的数据还未被写入数据库，此时查询到的数据就不是最新的数据。