如何保证Redis和数据库的一致性

关注我，升职加薪就是你！
当我们对数据进行修改的时候，到底是先删缓存，还是先写数据库？
1、如果先删缓存，再写数据库：在高并发场景下，当第一个线程删除了缓存，还没来得及写数据库，第二个线程来读取数据，会发现缓存中的数据为空，那就会去读数据库中的数据（旧值，脏数据），读完之后，把读到的结果写入缓存（此时，第一个线程已经将新的值写到缓存里面了），这样缓存中的值就会被覆盖为修改前的脏数据。
解决方案：
（1）先操作缓存，但是不会删除缓存。将缓存修改为一个特殊值（-999）。客户端读缓存时，发现是默认值，就休眠一小会，再去查一次Redis。
此方案存在的缺点：
a. 特殊值对业务有侵入。
b. 休眠时间内，可能会存在多次重复，对性能有影响。
（2）延时双删。先删除缓存，然后写数据库，休眠一小会，再次删除缓存。
此方案存在的缺点：如果数据写操作频繁，同样还是会有脏数据的问题。
总结：在这种方式下，通常要求写操作不会太频繁。
2、先写数据库，再删缓存：如果数据库写完了之后，缓存删除失败，数据就会不一致。
解决方案：
（1）给缓存设置一个过期时间。
此方案存在的问题是：过期时间内，缓存数据不会更新。
（2）引入MQ，保证原子操作。两个消费者，一个消费者负责删除Redis ，一个消费者负责写数据库。
解决方案：将热点数据缓存设置为永不过期，但是再value当中写入一个逻辑上的过期时间，另外起一个后台线程，扫描这些key，对于已逻辑上过期的缓存，进行删除。
总结：始终只能保证一定时间内的最终一致性。
关注我，升职加薪就是你！