数据源不是数据库的情况
数据源是其他远程服务，无法主动知道数据的变更，此时怎么保证一致性？
这个时候可以设置一个key的过期时间，过期时间到了此时可以异步去查远程服务中的数据，而缓存中虽然过期了先还是用着（防止没查到key还没了），查到了再更新key。
数据源是数据库中
严格要求一致性的情况：
读请求与写请求串行化（非常吃性能）
允许缓存可以稍微的跟数据库偶尔有不一致的情况
更新的时候，先更新数据库，然后再删除缓存。
（在已更新数据库还没删除缓存前，此时会有缓存与数据库不一致的情况）为什么是删除缓存而不是更新缓存？
这个缓存不一定用得到，有频繁修改但是只被读取了一两次的情况，有时候也不是那么好更新，比如缓存的数据可能需要先查询不同的表之后计算得到，而不是简单的单表中的数据。
为什么先更新数据库？
考虑并发情况，先删除了缓存，还没更新数据库，这个时候其他请求来查询，又更新了一遍缓存，此时更新完数据库，拿到的是旧值，而数据库中是新的，GG。
非并发的情况：先删除缓存，再更新数据库，这样也不会有一致性的问题
就数据库-缓存这个简单的模型而言
无非是讨论在更新数据库前后进行缓存的操作，并且讨论是删除缓存还是更新缓存
1.先更新缓存，再更新数据库
A查，B更新。B更新完缓存，还没更新数据库；这时候A去查缓存就查到更新后的数据，但事实是还没有真正更新。不可能通过这个方案。PASS
2.先删除缓存，再更新数据库
(1)请求A进行写操作，删除缓存
(2)请求B查询发现缓存不存在
(3)请求B去数据库查询得到旧值
(4)请求B将旧值写入缓存
(5)请求A将新值写入数据库
上面五步导致数据不一致，那么解决方案呢？
异步延时双删。先删除缓存，然后更新数据库。此时创建一个异步线程，睡眠一定时间后（休眠时间则在读数据业务逻辑的耗时基础上，加几百ms即可）再次进行缓存删除。
3.先更新数据库，再删除缓存
(1)缓存刚好失效
(2)请求A查询数据库，得一个旧值
(3)请求B将新值写入数据库
(4)请求B删除缓存
(5)请求A将查到的旧值写入缓存
如何解决上述并发问题?首先，给缓存设有效时间是一种方案。其次，采用上一个方法里给出的异步延时删除策略，保证读请求完成以后，再进行删除操作。
如果删缓存失败了怎么办，那不是会有不一致的情况出现么。比如一个写数据请求，然后写入数据库了，删缓存失败了，这会就出现不一致的情况了。这也是上一个方案里会存在的问题。
可以借助消息队列，在更新数据库成功后把删缓存的操作加到消息队列中保证成功。
image.png
4.先更新数据库，再更新缓存
一般是持反对的态度。
原因一(线程安全角度)同时有请求A和请求B进行更新操作，那么会出现
(1)线程A更新了数据库
(2)线程B更新了数据库
(3)线程B更新了缓存
(4)线程A更新了缓存
这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据，因此不考虑。
原因二(业务场景角度)有如下两点：
(1)如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。
(2)如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是浪费性能的。显然，删除缓存更为适合。
网友评论