缓存与数据库一致性

最新推荐文章于 2024-03-18 20:46:54 发布

「已注销」

最新推荐文章于 2024-03-18 20:46:54 发布

阅读量117

点赞数

文章标签：数据库

1.使用缓存的场景

缓存是提高系统读性能的常用技术，尤其对于读多写少的应用场景，使用缓存可以极大的提高系统的性能

例子：查询用户的存款： select money from user where uid = YYY;

为了优化该查询功能，我们可以在缓存中建立uid->money的键值对。

减少数据库的查询压力。

2. 读操作流程

目前数据库和缓存中都有存储数据，当读取数据的时候，流程如下。

1）先读取缓存是否存在数据(uid->money)。如果缓存中有数据返回结果。

2）如果缓存中没有数据，则从数据库中读取数据。

介绍一个概念：

缓存命中率：缓存命中数/总缓存访问数。

3. 写操作流程

在介绍写操作流程之前，先讨论两个问题

问题一：淘汰缓存还是更新缓存？

淘汰缓存：数据只会写入数据库，不会写入缓存，只会把数据淘汰掉。

更新缓存：数据不但写入数据库，还会写入缓存。

问题二：先写缓存还是先写数据库？

由于对缓存的更新和数据库的更新无法保证事务性操作。一定涉及到哪个先做，哪个后做的问题，我们的原则是采取对业务影响小的策略。下面是四种不同的组合策略

由此可见第四种策略的影响最小，只会造成一次查询缓存miss而已。那么当查询缓存miss的时候，我们该怎么办？很简单，查询数据库，然后将数据库的内容更新到缓存中。可能有人会问第四种策略，如果一上来淘汰缓存就失败了怎么办，当然是直接返回即可，通知用户本次操作失败。

我们的结论是：先淘汰缓存，再写数据库。

4. 分布式环境下如何保证一致性

下面我们再简单回顾下”先淘汰缓存，再写数据库 ”策略的读写流程。

写流程：

1）先淘汰缓存

2）再写数据库

读流程：

1）先读缓存，如果数据命中则返回

2）如果数据未命中则读取数据库

3）将数据库读出来的数据写入缓存

4.1 不一致性的例子

我们的这种策略在串行执行的情况，保证一致性是没有问题的。但是在分布式环境下，数据的读写都是并发的，可能有多个服务对同一个数据进行读写，也就是说后发出来的请求有可能先完成。我们来举个例子

1: 发送了写请求A，A的第一步淘汰了cache(如上图中的1)

2: A的第二步写数据库，发出修改请求（如上图中的2）

3: 发送了读请求B，B的第一步读取cache, 发现cache中是空的（如上图中的3）

4: B的第二步读取数据库，发出读取请求，此时A的第二步写数据还没完成，读出了脏数据，并放入了cache(如上图中的4)。即后发出的请求4比先发出的请求2先完成了，读出了脏数据，脏数据又入了缓存，造成缓存与数据库中的数据不一致。

4.2解决思路

我们来仔细看一下上面的例子，其实问题就出在对同一数据读取/写入请求不是串行的，而是并发的。那么如何能做到对同一数据的读取/写入请求是串行的？只需要让”同一数据的访问通过同一条DB连接执行 ”就行。如何做到这一点？可以修改获取DB连接的方法CPool.DBConnection(), 修改为CPool.DBConnection(uuid)[返回uuid取模相关联的连接]。

等等，”CPool.DBConnection(uuid)”这个代码是运行在每个service上面的，这样只能保证每个service上面是同一条DB连接。如何解决这个问题？聪明如你，可以在应用层根据uuid取模，来获取相关的service。这样就能保证同一数据的请求消息，都会路由到同一个service。