Redis读写缓存模式

1. Cache Aside Pattern(旁路缓存模式)

常用的缓存模式，适合读请求比较多的场景，同时维持缓存和数据库，以数据库结果为准
* 读过程：先从缓存中读数据，读不到从数据库中获取，然后把数据库读到的数据放入缓存中。
* 写过程：先更新数据库，后删除缓存。

先删除缓存，后更新数据库

是不可以的，会产生数据不一致的情况，如果有两个线程AB，线程A删除数据X的缓存值，还没有修改数据库，这时线程B去读缓存，没读到从数据中读取旧的X值，写入缓存中，这时候线程A更新数据库中X的值，这样就导致其他线程进来的时候读取到旧的值。

先更新数据库，后删除缓存

也会产生数据不一致，如果线程 A 删除了数据库中的值，但还没来得及删除缓存值，线程 B 就开始读取数据了，那么此时，线程 B 查询缓存时，发现缓存命中，就会直接从缓存中读取旧值。不过，在这种情况下，如果其他线程并发读缓存的请求不多，那么，就不会有很多请求读取到旧值。而且，线程 A 一般也会很快删除缓存值，这样一来，其他线程再次读取时，就会发生缓存缺失，进而从数据库中读取最新值。所以，这种情况对业务的影响较小。

2. Read/Write Throught（缓存穿透模式）

开发少见，应用层读写只需要操作缓存，不需要关心后端数据库。应用层在操作缓存时，缓存层会自动从数据库中加载或写回到数据库中，这种策略的优点是，对于应用层的使用非常友好，只需要操作缓存即可，缺点是需要缓存层支持和后端数据库的联动。

3. Write Behind Pattern（异步缓存写入）

跟读写穿透很像，都是缓存把数据读取写入到数据库中，读写穿透是同步更新缓存和数据库，异步缓存是只更新缓存不直接更新数据库，而是异步批量的方式更新数据库。应对大量写操作的场景。缺点是如果数据还没来得及写入数据库，系统发生异常会导致数据不一致的问题，还可能导致缓存中的数据永远丢失。