redis缓存与数据库一致性问题解决

淡淡的烟草味﹌ 2024-04-19 15:16 87阅读 0赞

一、需求起因  
假设先写数据库，再淘汰缓存：第一步写数据库操作成功，第二步淘汰缓存失败，则会出现DB中是新数据，Cache中是旧数据，数据不一致【如下图：db中是新数据，cache中是旧数据】。

![20190919165248442.png][]

假设先淘汰缓存，再写数据库：第一步淘汰缓存成功，第二步写数据库失败【如下图：cache中无数据，db中是旧数据】。

![20190919165300399.png][]

结论：先淘汰缓存，再写数据库。

二、数据不一致原因  
先操作缓存，在写数据库成功之前，如果有读请求发生，可能导致旧数据入缓存，引发数据不一致。

写流程：  
1）先淘汰cache  
2）再写db  
读流程：  
1）先读cache，如果数据命中hit则返回  
2）如果数据未命中miss则读db  
3）将db中读取出来的数据入缓存  
什么情况下可能出现缓存和数据库中数据不一致呢？

![20190919165313114.png][]

在分布式环境下，数据的读写都是并发的，上游有多个应用，通过一个服务的多个部署（为了保证可用性，一定是部署多份的），对同一个数据进行读写，在数据库层面并发的读写并不能保证完成顺序，也就是说后发出的读请求很可能先完成（读出脏数据）：

a）发生了写请求A，A的第一步淘汰了cache（如上图中的1）  
b）A的第二步写数据库，发出修改请求（如上图中的2）  
c）发生了读请求B，B的第一步读取cache，发现cache中是空的（如上图中的步骤3）  
d）B的第二步读取数据库，发出读取请求，此时A的第二步写数据还没完成，读出了一个脏数据放入cache（如上图中的步骤4）  
即在数据库层面，后发出的请求4比先发出的请求2先完成了，读出了脏数据，脏数据又入了缓存，缓存与数据库中的数据不一致出现了

三、问题解决思路

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d3ZDA1MDE_size_16_color_FFFFFF_t_70][]  
能否做到先发出的请求一定先执行完成呢？常见的思路是“串行化”

上图是一个service服务的上下游及服务内部详细展开，细节如下：

1）service的上游是多个业务应用，上游发起请求对同一个数据并发的进行读写操作，上例中并发进行了一个uid=1的余额修改（写）操作与uid=1的余额查询（读）操作  
2）service的下游是数据库DB，假设只读写一个DB  
3）中间是服务层service，它又分为了这么几个部分  
3.1）最上层是任务队列  
3.2）中间是工作线程，每个工作线程完成实际的工作任务，典型的工作任务是通过数据库连接池读写数据库  
3.3）最下层是数据库连接池，所有的SQL语句都是通过数据库连接池发往数据库去执行的  
工作线程的典型工作流是这样的：  
void work\_thread\_routine()\{  
Task t = TaskQueue.pop(); // 获取任务  
// 任务逻辑处理，生成sql语句  
DBConnection c = CPool.GetDBConnection(); // 从DB连接池获取一个DB连接  
c.execSQL(sql); // 通过DB连接执行sql语句  
CPool.PutDBConnection(c); // 将DB连接放回DB连接池  
\}  
提问：任务队列其实已经做了任务串行化的工作，能否保证任务不并发执行？  
答：不行，因为  
（1）1个服务有多个工作线程，串行弹出的任务会被并行执行  
（2）1个服务有多个数据库连接，每个工作线程获取不同的数据库连接会在DB层面并发执行  
提问：假设服务只部署一份，能否保证任务不并发执行？ 答：不行，原因同上  
提问：假设1个服务只有1条数据库连接，能否保证任务不并发执行？  
答：不行，因为  
（1）1个服务只有1条数据库连接，只能保证在一个服务器上的请求在数据库层面是串行执行的  
（2）因为服务是分布式部署的，多个服务上的请求在数据库层面仍可能是并发执行的  
提问：假设服务只部署一份，且1个服务只有1条连接，能否保证任务不并发执行？ 答：可以，全局来看请求是串行执行的，吞吐量很低，并且服务无法保证可用性  
完了，看似无望了，

1）任务队列不能保证串行化  
2）单服务多数据库连接不能保证串行化  
3）多服务单数据库连接不能保证串行化  
4）单服务单数据库连接可能保证串行化，但吞吐量级低，且不能保证服务的可用性，几乎不可行，那是否还有解？  
解决方式

退一步想，其实不需要让全局的请求串行化，而只需要“让同一个数据的访问能串行化”就行。  
在一个服务内，如何做到“让同一个数据的访问串行化”，只需要“让同一个数据的访问通过同一条DB连接执行”就行。  
如何做到“让同一个数据的访问通过同一条DB连接执行”，只需要“在DB连接池层面稍微修改，按数据取连接即可”  
获取DB连接的CPool.GetDBConnection()【返回任何一个可用DB连接】改为  
CPool.GetDBConnection(longid)【返回id取模相关联的DB连接】  
这个修改的好处是：

1）简单，只需要修改DB连接池实现，以及DB连接获取处  
2）连接池的修改不需要关注业务，传入的id是什么含义连接池不关注，直接按照id取模返回DB连接即可  
3）可以适用多种业务场景，取用户数据业务传入user-id取连接，取订单数据业务传入order-id取连接即可  
这样的话，就能够保证同一个数据例如uid在数据库层面的执行一定是串行的

稍等稍等，服务可是部署了很多份的，上述方案只能保证同一个数据在一个服务上的访问，在DB层面的执行是串行化的，实际上服务是分布式部署的，在全局范围内的访问仍是并行的，怎么解决呢？能不能做到同一个数据的访问一定落到同一个服务呢？

能否做到同一个数据的访问落在同一个服务上？

上面分析了服务层service的上下游及内部结构，再一起看一下应用层上下游及内部结构

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d3ZDA1MDE_size_16_color_FFFFFF_t_70 1][]

上图是一个业务应用的上下游及服务内部详细展开，细节如下：

1）业务应用的上游不确定是啥，可能是直接是http请求，可能也是一个服务的上游调用  
2）业务应用的下游是多个服务service  
3）中间是业务应用，它又分为了这么几个部分  
3.1）最上层是任务队列【或许web-server例如tomcat帮你干了这个事情了】  
3.2）中间是工作线程【或许web-server的工作线程或者cgi工作线程帮你干了线程分派这个事情了】，每个工作线程完成实际的业务任务，典型的工作任务是通过服务连接池进行RPC调用  
3.3）最下层是服务连接池，所有的RPC调用都是通过服务连接池往下游服务去发包执行的  
工作线程的典型工作流是这样的：

voidwork\_thread\_routine()\{  
Task t = TaskQueue.pop(); // 获取任务  
// 任务逻辑处理，组成一个网络包packet，调用下游RPC接口  
ServiceConnection c = CPool.GetServiceConnection(); // 从Service连接池获取一个Service连接  
c.Send(packet); // 通过Service连接发送报文执行RPC请求  
CPool.PutServiceConnection(c); // 将Service连接放回Service连接池  
\}  
似曾相识吧？没错，只要对服务连接池进行少量改动：

获取Service连接的CPool.GetServiceConnection()【返回任何一个可用Service连接】改为CPool.GetServiceConnection(longid)【返回id取模相关联的Service连接】这样的话，就能够保证同一个数据例如uid的请求落到同一个服务Service上。  
由于数据库层面的读写并发，引发的数据库与缓存数据不一致的问题（本质是后发生的读请求先返回了），可能通过两个小的改动解决：

1）修改服务Service连接池，id取模选取服务连接，能够保证同一个数据的读写都落在同一个后端服务上  
2）修改数据库DB连接池，id取模选取DB连接，能够保证同一个数据的读写在数据库层面是串行的  
四、其他  
本篇文章的作用在于提出分布式缓存的问题  
实现思路还可以是分布式锁，这里只是抛砖引玉  
————————————————  
  
原文链接：[https://blog.csdn.net/qq\_27384769/article/details/79499373][https_blog.csdn.net_qq_27384769_article_details_79499373]

[https://blog.csdn.net/Thousa\_Ho/article/details/78900563][https_blog.csdn.net_Thousa_Ho_article_details_78900563]

[20190919165248442.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/6acbf323c3844d51ac8f8a5ed2b3f670.png
[20190919165300399.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/a38e33bffa1b408f9fda115cc1cdce68.png
[20190919165313114.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/ca37a0a8f8da4bcd98a120366f003acd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d3ZDA1MDE_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/8064804928134f8d8eb48127be6d3f05.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d3ZDA1MDE_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/1e625f11ab4a4c929df6996b37afda8d.png
[https_blog.csdn.net_qq_27384769_article_details_79499373]: https://blog.csdn.net/qq_27384769/article/details/79499373
[https_blog.csdn.net_Thousa_Ho_article_details_78900563]: https://blog.csdn.net/Thousa_Ho/article/details/78900563