数据库缓存双写一致性
Cache Aside Pattern
最经典的缓存+数据库读写的模式
- 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
- 更新的时候，先更新数据库，然后再删除缓存。
为什么不能更新呢？
主要是两个问题，第一个是缓存的数据不一定是单纯的查库，可能还需要计算。第二个就是如果有并发
请求B是最后请求的，那么应该是他最后更新缓存为正确的数据，但是有可能请求A处理的更慢，所以请求A更新了最后的缓存，就会存在不一致。
当然，Cache Aside Pattern也会有并发问题，比如
但是数据库读操作速度远快于写操作，所以存在脏数据的可能性为0。到这里基本上就结束了。
当然，如果真的存在，怎么办？
简单，双删就行了，即第一次删除缓存之后，等待一段时间重新再删一次。等待时间由具体业务决定，以及需要考虑到数据库主从同步时间等。某些业务场景上，还可以设置缓存的过期时间，这样最差的情况就是在超时时间内数据存在不一致，而且增加了写请求的耗时。
删除缓存失败了怎么办，解决方法如下
即引入消息队列，删除缓存失败的记录下来重复删除，直到成功方可。如此一来，万无一失。
先删除了缓存，再更新数据库
数据发生了变更，先删除了缓存，然后要去修改数据库，此时还没修改。一个请求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中。随后数据变更的程序完成了数据库的修改，数据不一致。
如果这时候使用双删必须控制好时间间隔，否则会因为数据库主从同步可能导致问题。
解决方案如下
更新数据的时候，根据数据的唯一标识，将操作路由之后，发送到一个 jvm 内部队列中。读取数据的时候，如果发现数据不在缓存中，那么将重新执行“读取数据+更新缓存”的操作，根据唯一标识路由之后，也发送到同一个 jvm 内部队列中。
一个队列对应一个工作线程，每个工作线程串行拿到对应的操作，然后一条一条的执行。这样的话，一个数据变更的操作，先删除缓存，然后再去更新数据库，但是还没完成更新。此时如果一个读请求过来，没有读到缓存，那么可以先将缓存更新的请求发送到队列中，此时会在队列中积压，然后同步等待缓存更新完成。
这里有一个优化点，一个队列中，其实多个更新缓存请求串在一起是没意义的，因此可以做过滤，如果发现队列中已经有一个更新缓存的请求了，那么就不用再放个更新请求操作进去了，直接等待前面的更新操作请求完成即可。
待那个队列对应的工作线程完成了上一个操作的数据库的修改之后，才会去执行下一个操作，也就是缓存更新的操作，此时会从数据库中读取最新的值，然后写入缓存中。
如果请求还在等待时间范围内，不断轮询发现可以取到值了，那么就直接返回；如果请求等待的时间超过一定时长，那么这一次直接从数据库中读取当前的旧值。
高并发的场景下，该解决方案要注意的问题
-
读请求长时阻塞
可能数据更新很频繁，导致队列中积压了大量更新操作，然后读请求会发生大量的超时，最后导致大量的请求直接走数据库。
需要根据业务情况，模拟最繁忙的时候队列中的积压，也许需要部署多个服务，分摊压力。一般来说，数据的写频率是很低的，因此实际上正常来说，在队列中积压的更新操作应该是很少的。 -
读请求并发量过高
本次更新时队列前面有一堆更新操作，突然间大量本次数据读请求会在几十毫秒的延时夯在服务上。
但是因为并不是所有的数据都在同一时间更新，缓存也不会同一时间失效，所以每次可能也就是少数数据的缓存失效了，然后那些数据对应的读请求过来，并发量应该也不会特别大。 -
多服务实例部署的请求路由
可能这个服务部署了多个实例，那么必须保证说，执行数据更新操作，以及执行缓存更新操作的请求，都通过 Nginx 服务器路由到相同的服务实例上。 -
热点商品的路由问题，导致请求的倾斜
万一某个商品的读写请求特别高，全部打到相同的机器的相同的队列里面去了，可能会造成某台机器的压力过大。
如果更新频率不是太高的话，这个问题的影响并不是特别大，但是的确可能某些机器的负载会高一些
参考