『延迟双删』和『先修改数据库，再删除缓存』哪个方案更好？
mysql 和 redis 数据一致性方案：『延迟双删』和『先修改数据库，再删除缓存』哪个方案更好？
哪些业务场景适合『延迟双删』；又有哪些业务场景适合『先修改数据库，再删除缓存』？
哪种方案在业内更加主流？
回答：
延迟双删是在先修改数据库再删除缓存的情况下，为了使缓存与数据库达到最终一致，再进行一次延迟删除，称为延迟双删
由于在修改数据库之前，此时缓存可能刚好失效，另一个读取请求进来之后发现缓存中不存在，就会从数据库读取数据，假设此时读取完但还没放到缓存中，这时修改数据库、删除缓存的操作执行先完成，那么读取完放到缓存中的数据就是旧数据，与数据库中的数据不一致
回答：
延时双删只是增加了一次redis的key的操作，消耗基本可以忽略不计！建议用延时双删！
以下是使用场景区别：
1.先改数据库再改缓存：对接口速度有要求，确保修改数据能在最短时间内同步的情况使用，以为它比延迟双删少了一次耗时计算和key操作。
使用场景如 ：任务部门操作同步延迟、常用模板生效时间延迟、监控人员坐标位置信息最快时间展示等
2.延时双删：可以接受一定延迟，并且一致性要求比较强的时候使用延时双删，延时双删，只是降低了同步不及时概率，并不是强一致性，延时时间是一个预估值，不能确保 mysql 和 redis 数据在这个时间段内都实时同步或持久化成功了
使用场景 如：基础数据平台提供数据给其他系统使用，要求数据及时同步，并且这个接口不会被频繁调用
以上是 『延迟双删』和『先修改数据库，再删除缓存』哪个方案更好？ 的全部内容， 来源链接： utcz.com/p/944744.html
