Redis缓存中的数据和数据库不一致

首先关于两者数据的一致性包含有两种情况：

　（1）缓存中有数据时，那数据库中的数据要和缓存中的数据相同；

　（2）缓存中没有数据时，数据库中的数据必须是最新的。

如果不符合以上两种情况，就属于缓存和数据库数据不一致的问题。

缓存不同的读写模式，所对应的不一致问题也会有所差异，缓存的读写模式主要有两种，读写缓存和只读缓存。

1.对于读写缓存来讲，需要关注缓存数据写完以后，对于数据库的写会策略，主要分为两种：

　（1）同步直写，写缓存的时候，也同步写数据库，这样数据一致，改策略适用于需要读写缓存和数据库数据一致的场景，但使用这种策略需要注意，缓存和数据库中的数据需要同时更新，所以需要在更新中使用事务机制，保证缓存和数据库的更新具有原子性，要么同时更新成功，要么都更新失败并返回错误信息，进行重试。

　（2）异步写回，写缓存时不写回数据库，等缓存中数据要被淘汰时，再写回数据库，但如果写完缓存，还未更新数据库时缓存出现故障，那要数据库中就没有最新的数据了，该种策略适用于对数据一致性要求不是那么高的场景，如电商商品的非关键属性和短视频的创建和修改时间等，可以使用该策略。

2.只读缓存的数据变更主要分为，增加新数据和删改已有的数据：

　（1）新增数据，对于新增数据，只需要直接添加到数据库中即可，不需要对缓存做什么操作。这样数据库中是最新的数据，缓存中没有新增数据，对应前面的数据一致性的第二种情况，也是数据一致的。

　（2）删改数据，如果发生删改数据，既要删改数据库中的数据，还要让缓存中的数据无效，同时还需要保证两个操作的原子性，要么都执行成功，要么都执行失败，不然都会导致数据不一致的情况发生，

　　　　a.先更新数据库，后删缓存。可能发生缓存删除失败，下次查询命中缓存，但读取到的是旧值

　　　　b.先删除缓存，后更新数据库。可能发生数据库更新失败，下次查询时缓存中没有，从数据库中获取的是未更新的旧值。

　　　　解决该种场景下的数据不一致问题，可以采用重试方法，考虑使用如Kafka消息队列，把要删改的数据放入到Kafka中，只有缓存和数据库同时操作成功时，才将其从消息队列中删除，否则重新读取并操作，重试次数超过一定限制时返回相应的错误。

　　　　对应上面两种删除的场景和顺序，由于执行先后的时间差的缘故，也有可能导致不同的数据不一致的问题出现，但也可以有针对性的不同解决策略：

　　　　　　1. 针对先删除缓存再更新数据库的场景，可能会出现线程A先删除了缓存但并没来得急更新数据库，这时线程B来读取，缓存中没有，将从数据库中读取，a.但读到的是旧值，b.同时还会导致将该旧值同步到缓存中。

　　　　　　　　解决方法：可以再线程A更新完数据库时，sleep一小段时间（这个时间要大于线程B从数据库中读取数据并更新缓存的时间），然后线程A再删除缓存，之后再有其他线程来读取时，发现缓存缺失，则会从数据库中读取最新的值，并更新至缓存中

　　　　　　　　　　　　　这个方法就叫做延迟双删。

　　　　　　2. 针对先更新数据库，后删除缓存这种场景，可能存在线程A先更新了数据库还没来及删除缓存的时候，线程B来读取并命中缓存，但是读到了旧值

　　　　　　　　解决方法：也可以使用延迟双删

　　　　总结下来：（1）对于更新数据库或者删除缓存可能失败导致的不一致，可以采用重试的方式解决；

　　　　　　　　　（2）对于删除缓存和更新数据库过程中，由于存在其他并发线程读取而导致的不一致问题，可以采用延迟双删的方法来解决。

　　　　建议使用先更新数据库，再删除缓存的顺序，原因如下：

　　　　　　　　（1）先删缓存，再更新数据库，可能由于缓存的缺失而访问数据库，进而给数据库带来压力

　　　　　　　　（2）如果业务应用中读取数据库和写缓存的时间不好估算，那么，延迟双删中的等待时间就不好设置。

PS：如果业务层要求必须读取一致性的数据，可以在更新数据库的同时，现在redis缓存暂存客户端并发读请求，等数据库更新完，缓存删除完，再来读取，保证数据一致性。

参考《Redis核心技术与实战》蒋德钧

巴特西