缓存与数据库一致性策略

Redis缓存由于其优秀的性能、丰富的数据结构常用于提高查询效率，但需要保证Redis缓存与数据库数据一致。本文分析缓存数据库一致性及可能发生的问题，说说一些常见解决思路。

背景

开发常用套路是先查缓存，如有则直接返回；没有则查库返回并写到缓存中。在数据变更的时候，则更新库然后更新缓存（一般是采用淘汰缓存，因为如果业务复杂情况下，由读操作从DB读取数据组装后更新缓存更方便、易维护）。

读操作流程逻辑不存在一致问题，在并发场景下，即使多个线程同时发现没有缓存，读库后更新缓存也能保证数据一致。

写操作一般存在这样两种策略：先更新库再淘汰缓存，先淘汰缓存再更新库。这两种策略会有不一样的表现。

先更新库再淘汰缓存

假设更新库update DB后，在淘汰缓存del cache时失败，即未淘汰缓存，则缓存是旧数据，会有数据不一致问题。

先淘汰缓存再更新库

假设先淘汰缓存，后更新数据库时失败，此时数据库是旧数据，由于缓存已淘汰，在读操作从库读到缓存时仍是旧数据，不存在一致问题。

因此，最佳实践是先淘汰缓存、再更新库

数据不一致原因

据上面的分析，我们的缓存采用方案的是先淘汰缓存、再更新库。但即使这样，在某些情况下如并发较高的场景下，数据可能仍面临一致性问题。

假设在集群系统下，写请求在淘汰缓存成功后，由于诸如CPU调度、FULL GC等原因导致并更新库比平常慢了一些，也即在两个操作之间系统突然“卡顿”了一下；此时另外一个读请求刚好在这个时间间隔中，发现no cache于是从库中读取到更新之前的旧数据，从而导致数据不一致。

当然这种情况发生的概率极低，但是在并发较高或系