缓存更新的套路
这个coolshell的文章我看过了两三次,有事没事想起来一下,这几天看了看分布式相关的,又看到了有人谈缓存的更新策略。所以我还是也自己总结一下把。这篇文章前面说的很详细了。但是结尾的那一部分简单的带过了两个更新,其中一个失败的问题。
我这里来列一个各种更新策略的问题吧。
1.先删缓存,再更新数据库
- case1
客户端A要写数据,B要读数据
A先删除了缓存。
B刚好要读这个数据,先读了缓存,找不到。
B去数据库里拿到了数据
B又放进了缓存,此时缓存是旧数据。
A去写了数据。
结束,脏数据出来了。
这样的时序并不难产生,分布式下,A只要有网络延迟或者GC下,都是可能的。
即使在网络无问题的情况下,这个可能性也是很大的。因为读操作的速度比写快,所以B只要时间点刚好,很大可能有这个问题。
2.先更新数据库,再更新缓存
我自己瞎想的,应该没人这么干
- case2
A要写数据,先写缓存。成功
A还没有来及写数据库,挂了。或者就是单纯的写失败。
结束,脏数据。
3.先更新数据库,后更新缓存。
- case3
A,B都要写那个数据。
A先来了,先写数据库变成了1,
B来了,写数据库变成了2,
B修改缓存的request先到了缓存,变成了2.
A的反而后到,写缓存变成了1.
结束,数据库里是2,缓存里是1,脏数据了。
这个可能性也很大,两步的操作并不是原子操作。
4.先更新数据库,再删除缓存
- case4
B要写,A要读。
A先到了,发现缓存里没有
A去数据库里读到了数据1
B到了要写数据库,修改成了2
B去缓存尝试删掉原来1的缓存,发现没有就不操作。
A设置缓存的request刚到,把缓存设置了1
结束,缓存是1,数据库是2,又脏数据了。
考虑网络延迟,刚好把B的更新缓存卡在了最后一步,这个是很可能发生的。
再不考虑网络的情况下。B的读操作,完成比较快,A写的慢,所以发生概率较小。
比较case3和case4
再coolshell里面聊到了case4要比case3发生的概率小。我觉得不尽然,
- 从导致乱序所延迟的时间来说,两者其实都一样。
对于case3. A写完数据库瞬间---->写缓存的request到达,延迟:B写一个数据+B写一个缓存。
对于case4. A读完数据库瞬间----->写缓存的request到达,延迟:B写一个数据+B删一个缓存。
所以两个case的延迟时间是差不多得(对于缓存的写和删差距差距应该不会大)。 - 发生的条件,其实也是相似。
对于case3. A,B都来写,A写完B写,都是写操作所以要加锁,真个是transaction的,在发生乱序之前是很正常的状态,顺序写数据库吗。
对于case4,A来数据库,完成了,然后B来写。在发生乱序前也是很正常的事情。
从A操作数据库完成那一刻,两个的缓存操作都要被延迟了相等的时间,就会发生上面说的那种脏数据。所以case3 和 case4的发生条件基本相同。
唯一一点case4比case3小概率的是:case4要求没有缓存存在。对于一个好的缓存系统,你得命中个50%吧?那其实低就只定在这个情况上呗。降低的概率也是肉眼可见的,不是说极其罕见的。只要case3的问题敢发生,那case4的也大概率会发生。我估计我没有哪里推理错吧。。
其中一步失败的情况。
https://blog.csdn.net/u012129558/article/details/52278091
这个文章说了先删缓存还是先更新数据库。结论是先删缓存。
原因:
先更新数据库的话,如果第二部更新缓存失败,那就是脏数据。反过来,只是会导致下次缓存不命中。
博主以先删缓存的为基础,尝试保证数据库操作的严格串行,最后整到了让对一个data落到同一个service上面。其实即使做到了,也依然不能通过case1的问题,因为两个不是原子操作,并不能保证AB去操作数据库的顺序,即使能保证先到的先完成。
不过这个解决思路是对同一个数据的修改落到同一个service上,那这样的话其实缓存也不存在分布式问题了,因为同一个数据的缓存就只有一个service来串行修改啦,想怎么弄,怎么弄。
网友评论