重庆高端设计公司朝阳区seo
保证数据一致性：指保证redis里的数据和mysql的数据是一致的，不能说mysql更新了，但redis里面的还是旧的数据，反之亦然
先说结论：增删改的时候，把Redis中的缓存删了
为什么不先更新数据库，再更新缓存？
如果更新后不一定被读取，那么会进行很多次无意义的更新，万一你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是浪费性能的。显然，删除缓存更为适合。
那先写入库还是先删缓存呢？
- 如果先删除缓存再写入库：还没来得及写入，就有线程来读取，这时候发现缓存为空，然后就去读了数据库旧数据并写入缓存，在数据库更新后发现数据不一致（此时缓存中为脏数据）
- 如果先写入库再删除缓存：先写了库，但线程挂了缓存没删，这时候直接读旧缓存，也会数据不一致。
最终选择：先写入库再删缓存，并采取措施保证删除操作
最简单最基础的措施：延迟双删
基本思路：在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。
具体步骤：
1、删缓存；
2、写入数据库；
3、休眠500毫秒（看情况定）
4、再次删除缓存
但问题是：删除失败怎么办？
可以改成异步重试删除，有很多种方法可以进行重试
- 单独起一个线程，但可能会创建太多线程导致OOM，不建议用；
- 交给线程池处理，但如果服务器重启，部分数据可能会丢失，不建议用；
- 交给定时任务进行重试，比如elastic-job，定时1秒删除一次，尝试5次（自己决定），缺点是实时性不高；
- 交给mq等消息中间件，让删除缓存的消费者进行重试
- 订阅mysql的binlog，在订阅者中，如果发现了更新数据请求，则删除相应的缓存。（最常用）
具体来说：当一条数据发生修改时，MySQL 就会产生一条变更日志（Binlog），我们可以用消息队列订阅这个日志（而不是代码！用的是阿里的canel插件），拿到日志中具体操作的数据，再根据这条数据，用消息队列去删除对应的缓存，由专门的消费者来不断重试，直到删除成功。
过程:
1）更新数据库（增删改）
2）通过canal监听binlog，把监听到的binlog 数据发送到 MQ 队列中
3）通过消息队列的"删除缓存消费者"将缓存数据删除（缓存删除失败则通过MQ不断重试，直至删除成功）(用死信队列)