分布式中的缓存更新策略 比较
2019-02-12 本文已影响0人
听海吹牛逼的声音
缓存更新的套路
这个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来串行修改啦，想怎么弄，怎么弄。
