避免缓存中出现脏数据分析

Posted 2022-06-19 tuhooo

缓存能解决的问题

• 提升性能

  绝大多数情况下，select 是出现性能问题最大的地方。一方面，select 会有很多像 join、group、order、like 等这样丰富的语义，而这些语义是非常耗性能的；另一方面，大多 数应用都是读多写少，所以加剧了慢查询的问题。

  分布式系统中远程调用也会耗很多性能，因为有网络开销，会导致整体的响应时间下降。为了挽救这样的性能开销，在业务允许的情况（不需要太实时的数据）下，使用缓存是非常必要的事情。

• 缓解数据库压力

  当用户请求增多时，数据库的压力将大大增加，通过缓存能够大大降低数据库的压力。

缓存的适用场景

• 对于数据实时性要求不高

  对于一些经常访问但是很少改变的数据，读明显多于写，适用缓存就很有必要。比如一些网站配置项。

• 对于性能要求高

  比如一些秒杀活动场景。

缓存三种模式

一般来说，缓存有以下三种模式：

• Cache Aside 更新模式

• Read/Write Through 更新模式

• Write Behind Caching 更新模式

缓存的各种操作

写就是更新，更新就是写。

读

• R_1：先读缓存，读到了缓存则返回，读不到缓存则去读数据库，直接返回读到数据，不操作缓存
• R_2：先读缓存，读到了缓存则返回，读不到缓存则去读数据库，将数据库中读到的数据更新到缓存中

写

• W_1：先写缓存，再写数据库
• W_2：先写数据库，库再写缓存
• W_3：先删除缓存，再写数据库
• W_4：先写数据库，再删缓存

两种不同的读操作是互斥的，而写操作细分为：删除和更新，这两种操作也是互斥的，所以可能的组合其实只有这四种：

• （R_1，W_1）
• （R_1，W_2）
• （R_2，W_3）
• （R_2，W_4）

排列组合，逐个分析

由于 R_1 在读的时候不去操作缓存的，所以写操作要包括写缓存的操作。也就是有两种情况：（R_1，W_1），（R_1，W_2）

（R_1，W_1）分析

A：先写缓存，再写数据库，数据库写入成功，这是最理想的状况，并发的写操作不会带来脏数据

B：先写缓存，再写数据库，最后数据库写入失败，导致缓存中写入了脏数据

C：C 在 B 的基础上做了改良，当发现写数据库失败时，旋即把缓存删除掉；缺点就是在【写缓存结束，发现更新失败】这个时间区间内，缓存中的其实是脏数据

结论：（R_1，W_1）可用性存疑

（R_1，W_2）分析

这个图一画完，其实你就知道了，先写数据库，再写缓存这种策略很容易就产生缓存的脏数据了，很好复现。

结论：（R_1，W_2）完全不可用，PASS

（R_2，W_3）分析

 

（R_2，W_3）这种操作和（R_1，W_1）中场景 C 有点类似，就是在【删除缓存，更新 DB 结束】这段时间内，发现缓存没了，然后读库，再写缓存，其实是有脏数据的。

（R_2，W_4）分析

先更新数据，后删除缓存会脏成脏数据的时间范围是：【更新数据库成功，删除缓存】这段时间，这个时间间隔非常短，所以策略是最优的。

结论：（R_2，W_4）策略最优

 

整体结论：

（R_2，W_4） > （R_2，W_3）= （R_1，W_1） > （R_1，W_2）

思考

对脏数据的理解，什么是脏数据：缓存中的数据和 DB 中的数据不一致即为脏数据。

正是由于更新 DB 和更新 Cache 无法做到原子性，所以才会导致数据出现不一致的情况。

所以缓存的脏数据从根本上是无法避免的，只能尽量减少发生的概率。

减少发生概率的方法就是，减少出现不一致概率的时间区间。

一定要有意识，应用的所有读写都是并发的，要在这个背景下去考虑问题，所以画图理解是最好的办法。

数据库的读写要有基本概念：速度快慢，一致性，并发，阻塞等。

 

暂时搞懂了这个问题，下一步就是写代码验证。