Redis面试篇--如何保证缓存与数据库的双写一致性？

　　如果不是严格要求“缓存和数据库”必须保证⼀致性的话，最好不要做这个⽅案：即 读请求和写请求串⾏化，串到⼀个内存队列⾥⾯去。串⾏化可以保证⼀定不会出现不⼀致的情况，但会导致系统吞吐量⼤幅度降低。解决这个问题的最经典的模式，就是Cache Aside Pattern。Cache Aside Pattern：

（1）读的时候先读缓存，如果缓存不存在的话就读数据库，取出数据库后更新缓存；如果存在的话直接读取缓存的信息。 （2）写的时候，先更新数据库，再删除缓存。说到这个问题，⼜会出现很多问题：

（1）为什么是删除缓存，⽽不是更新缓存？

（2）为什么是先更新数据库，再删除缓存？不是先删除缓存，再更新数据库？

写的时候为什么是删除缓存不是更新缓存？

　　很多时候复杂的缓存场景，缓存不是仅仅从数据库中取出来的值。可能是关联多张表的数据并通过计算才是缓存需要的值。并且，更新

缓存的代价有时候很⾼。对于需要频繁写操作，⽽读操作很少的时候，每次进⾏数据库的修改，缓存也要随之更新，会造成系统吞吐的下降，但此时缓存并不会被频繁访问到，⽤到的缓存才去算缓存。

　 删除缓存⽽不是更新缓存，是⼀种懒加载的思想，不是每次都重复更新缓存，只有⽤到的时候才去更新缓存，同时即使有⼤量的读请求，实际也就更新了⼀次，后⾯的请求不会重复读。

Cache Aside Pattern存在的问题

问题：先更新数据库，再删除缓存，如果更新缓存失败了，导致数据库中是新数据，缓存中是旧数据，就出现数据不⼀致的问题。解决思路：先删除缓存，再更新数据库。

缓存删除失败：如果缓存删除失败，那么数据库信息没有被修改，保持了数据的⼀致性；

缓存删除成功，数据库更新失败：此时数据库⾥的是旧数据，缓存是空的，查询时发现缓存不存在，就查询数据库并更新缓存，数据保持⼀致。

问题：上⾯的⽅案存在不⾜，如果删除完缓存更新数据库时，如果⼀个请求过来查询数据，缓存不存在，就查询数据库的旧数据，更新旧数据到缓存中。随后数据更新完成，修改了数据库的数据，此时缓存和数据库的数据就会出现不⼀致了。⾼并发下会出现这种数据库+缓存不⼀致的情况。 如果不采⽤给缓存设置过期时间策略，该数据永远都是脏数据。

解决⽅案：采⽤双删除策略。写请求先删除缓存，再去更新数据库，等待⼀段时间后异步删除缓存。这样可以保证在读取错误数据时能及时被修正过来。

还有⼀种策略，就是：写请求先修改缓存为指定值，然后再去更新数据库，再更新缓存。读请求过来后，会先读缓存，判断是指定值后就进⼊循环读取状态，等到写请求更新缓存。如果循环超时就去数据库读取数据，更新缓存。这种⽅案保证了读写的⼀致性，但由于读请求等待写请求的完成，会降低系统的吞吐量。