缓存与数据库一致性保证（二）

本文主要讨论这么几个点&＃xff1a;

&＃xff08;1&＃xff09;啥时候数据库和缓存中的数据会不一致

&＃xff08;2&＃xff09;不一致优化思路

&＃xff08;3&＃xff09;如何保证数据库与缓存的一致性

一、需求缘起

上一篇《缓存架构设计细节二三事》&＃xff08;点击查看&＃xff09;引起了广泛的讨论&＃xff0c;其中有一个结论&＃xff1a;当数据发生变化时&＃xff0c;“先淘汰缓存&＃xff0c;再修改数据库”这个点是大家讨论的最多的。

上篇文章得出这个结论的依据是&＃xff0c;由于操作缓存与操作数据库不是原子的&＃xff0c;非常有可能出现执行失败。

假设先写数据库&＃xff0c;再淘汰缓存&＃xff1a;第一步写数据库操作成功&＃xff0c;第二步淘汰缓存失败&＃xff0c;则会出现DB中是新数据&＃xff0c;Cache中是旧数据&＃xff0c;数据不一致【如上图&＃xff1a;db中是新数据&＃xff0c;cache中是旧数据】。

假设先淘汰缓存&＃xff0c;再写数据库&＃xff1a;第一步淘汰缓存成功&＃xff0c;第二步写数据库失败&＃xff0c;则只会引发一次Cache miss【如上图&＃xff1a;cache中无数据&＃xff0c;db中是旧数据】。

结论&＃xff1a;先淘汰缓存&＃xff0c;再写数据库。

引发大家热烈讨论的点是“先操作缓存&＃xff0c;在写数据库成功之前&＃xff0c;如果有读请求发生&＃xff0c;可能导致旧数据入缓存&＃xff0c;引发数据不一致”&＃xff0c;这就是本文要讨论的主题。

二、为什么数据会不一致

回顾一下上一篇文章中对缓存、数据库进行读写操作的流程。

写流程&＃xff1a;

&＃xff08;1&＃xff09;先淘汰cache

&＃xff08;2&＃xff09;再写db

读流程&＃xff1a;

&＃xff08;1&＃xff09;先读cache&＃xff0c;如果数据命中hit则返回

&＃xff08;2&＃xff09;如果数据未命中miss则读db

&＃xff08;3&＃xff09;将db中读取出来的数据入缓存

什么情况下可能出现缓存和数据库中数据不一致呢&＃xff1f;

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

&＃xff08;a&＃xff09;发生了写请求A&＃xff0c;A的第一步淘汰了cache&＃xff08;如上图中的1&＃xff09;

&＃xff08;b&＃xff09;A的第二步写数据库&＃xff0c;发出修改请求&＃xff08;如上图中的2&＃xff09;

&＃xff08;c&＃xff09;发生了读请求B&＃xff0c;B的第一步读取cache&＃xff0c;发现cache中是空的&＃xff08;如上图中的步骤3&＃xff09;

&＃xff08;d&＃xff09;B的第二步读取数据库&＃xff0c;发出读取请求&＃xff0c;此时A的第二步写数据还没完成&＃xff0c;读出了一个脏数据放入cache&＃xff08;如上图中的步骤4&＃xff09;

即在数据库层面&＃xff0c;后发出的请求4比先发出的请求2先完成了&＃xff0c;读出了脏数据&＃xff0c;脏数据又入了缓存&＃xff0c;缓存与数据库中的数据不一致出现了

三、不一致优化思路

能否做到先发出的请求一定先执行完成呢&＃xff1f;常见的思路是“串行化”&＃xff0c;今天将和大家一起探讨“串行化”这个点。

先一起细看一下&＃xff0c;在一个服务中&＃xff0c;并发的多个读写SQL一般是怎么执行的

上图是一个service服务的上下游及服务内部详细展开&＃xff0c;细节如下&＃xff1a;

&＃xff08;1&＃xff09;service的上游是多个业务应用&＃xff0c;上游发起请求对同一个数据并发的进行读写操作&＃xff0c;上例中并发进行了一个uid&＃61;1的余额修改&＃xff08;写&＃xff09;操作与uid&＃61;1的余额查询&＃xff08;读&＃xff09;操作

&＃xff08;2&＃xff09;service的下游是数据库DB&＃xff0c;假设只读写一个DB

&＃xff08;3&＃xff09;中间是服务层service&＃xff0c;它又分为了这么几个部分

&＃xff08;3.1&＃xff09;最上层是任务队列

&＃xff08;3.2&＃xff09;中间是工作线程&＃xff0c;每个工作线程完成实际的工作任务&＃xff0c;典型的工作任务是通过数据库连接池读写数据库

&＃xff08;3.3&＃xff09;最下层是数据库连接池&＃xff0c;所有的SQL语句都是通过数据库连接池发往数据库去执行的

工作线程的典型工作流是这样的&＃xff1a;

void work_thread_routine(){

Task t &＃61; TaskQueue.pop(); // 获取任务

// 任务逻辑处理&＃xff0c;生成sql语句

DBConnection c &＃61; CPool.GetDBConnection(); // 从DB连接池获取一个DB连接

c.execSQL(sql); // 通过DB连接执行sql语句

CPool.PutDBConnection(c); // 将DB连接放回DB连接池

}

&＃xff1a;任务队列其实已经做了任务串行化的工作&＃xff0c;能否保证任务不并发执行&＃xff1f;

&＃xff1a;不行&＃xff0c;因为

&＃xff08;1&＃xff09;1个服务有多个工作线程&＃xff0c;串行弹出的任务会被并行执行

&＃xff08;2&＃xff09;1个服务有多个数据库连接&＃xff0c;每个工作线程获取不同的数据库连接会在DB层面并发执行

&＃xff1a;假设服务只部署一份&＃xff0c;能否保证任务不并发执行&＃xff1f;

&＃xff1a;不行&＃xff0c;原因同上

&＃xff1a;假设1个服务只有1条数据库连接&＃xff0c;能否保证任务不并发执行&＃xff1f;

&＃xff1a;不行&＃xff0c;因为

&＃xff08;1&＃xff09;1个服务只有1条数据库连接&＃xff0c;只能保证在一个服务器上的请求在数据库层面是串行执行的

&＃xff08;2&＃xff09;因为服务是分布式部署的&＃xff0c;多个服务上的请求在数据库层面仍可能是并发执行的

&＃xff1a;假设服务只部署一份&＃xff0c;且1个服务只有1条连接&＃xff0c;能否保证任务不并发执行&＃xff1f;

&＃xff1a;可以&＃xff0c;全局来看请求是串行执行的&＃xff0c;吞吐量很低&＃xff0c;并且服务无法保证可用性

完了&＃xff0c;看似无望了&＃xff0c;

1&＃xff09;任务队列不能保证串行化

2&＃xff09;单服务多数据库连接不能保证串行化

3&＃xff09;多服务单数据库连接不能保证串行化

4&＃xff09;单服务单数据库连接可能保证串行化&＃xff0c;但吞吐量级低&＃xff0c;且不能保证服务的可用性&＃xff0c;几乎不可行&＃xff0c;那是否还有解&＃xff1f;

退一步想&＃xff0c;其实不需要让全局的请求串行化&＃xff0c;而只需要“让同一个数据的访问能串行化”就行。

在一个服务内&＃xff0c;如何做到“让同一个数据的访问串行化”&＃xff0c;只需要“让同一个数据的访问通过同一条DB连接执行”就行。

如何做到“让同一个数据的访问通过同一条DB连接执行”&＃xff0c;只需要“在DB连接池层面稍微修改&＃xff0c;按数据取连接即可”

获取DB连接的CPool.GetDBConnection()【返回任何一个可用DB连接】改为

CPool.GetDBConnection(longid)【返回id取模相关联的DB连接】

这个修改的好处是&＃xff1a;

&＃xff08;1&＃xff09;简单&＃xff0c;只需要修改DB连接池实现&＃xff0c;以及DB连接获取处

&＃xff08;2&＃xff09;连接池的修改不需要关注业务&＃xff0c;传入的id是什么含义连接池不关注&＃xff0c;直接按照id取模返回DB连接即可

&＃xff08;3&＃xff09;可以适用多种业务场景&＃xff0c;取用户数据业务传入user-id取连接&＃xff0c;取订单数据业务传入order-id取连接即可

这样的话&＃xff0c;就能够保证同一个数据例如uid在数据库层面的执行一定是串行的

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

四、能否做到同一个数据的访问落在同一个服务上&＃xff1f;

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

上图是一个业务应用的上下游及服务内部详细展开&＃xff0c;细节如下&＃xff1a;

&＃xff08;1&＃xff09;业务应用的上游不确定是啥&＃xff0c;可能是直接是http请求&＃xff0c;可能也是一个服务的上游调用

&＃xff08;2&＃xff09;业务应用的下游是多个服务service

&＃xff08;3&＃xff09;中间是业务应用&＃xff0c;它又分为了这么几个部分

&＃xff08;3.1&＃xff09;最上层是任务队列【或许web-server例如tomcat帮你干了这个事情了】

&＃xff08;3.2&＃xff09;中间是工作线程【或许web-server的工作线程或者cgi工作线程帮你干了线程分派这个事情了】&＃xff0c;每个工作线程完成实际的业务任务&＃xff0c;典型的工作任务是通过服务连接池进行RPC调用

&＃xff08;3.3&＃xff09;最下层是服务连接池&＃xff0c;所有的RPC调用都是通过服务连接池往下游服务去发包执行的

工作线程的典型工作流是这样的&＃xff1a;

voidwork_thread_routine(){

Task t &＃61; TaskQueue.pop(); // 获取任务

// 任务逻辑处理&＃xff0c;组成一个网络包packet&＃xff0c;调用下游RPC接口

ServiceConnection c &＃61; CPool.GetServiceConnection(); // 从Service连接池获取一个Service连接

c.Send(packet); // 通过Service连接发送报文执行RPC请求

CPool.PutServiceConnection(c); // 将Service连接放回Service连接池

}

似曾相识吧&＃xff1f;没错&＃xff0c;只要对服务连接池进行少量改动&＃xff1a;

获取Service连接的CPool.GetServiceConnection()【返回任何一个可用Service连接】改为

CPool.GetServiceConnection(longid)【返回id取模相关联的Service连接】

这样的话&＃xff0c;就能够保证同一个数据例如uid的请求落到同一个服务Service上。

五、总结

由于数据库层面的读写并发&＃xff0c;引发的数据库与缓存数据不一致的麻烦&＃xff08;本质是后发生的读请求先返回了&＃xff09;&＃xff0c;可能通过两个小的改动解决&＃xff1a;

&＃xff08;1&＃xff09;修改服务Service连接池&＃xff0c;id取模选取服务连接&＃xff0c;能够保证同一个数据的读写都落在同一个后端服务上

&＃xff08;2&＃xff09;修改数据库DB连接池&＃xff0c;id取模选取DB连接&＃xff0c;能够保证同一个数据的读写在数据库层面是串行的

六、遗留

取模访问服务是否会影响服务的可用性&＃xff1f;

&＃xff1a;不会&＃xff0c;当有下游服务挂掉的时候&＃xff0c;服务连接池能够检测到连接的可用性&＃xff0c;取模时要把不可用的服务连接排除掉。

&＃xff1a;取模访问服务与 取模访问DB&＃xff0c;是否会影响各连接上请求的负载均衡&＃xff1f;

&＃xff1a;不会&＃xff0c;只要数据访问id是均衡的&＃xff0c;从全局来看&＃xff0c;由id取模获取各连接的概率也是均等的&＃xff0c;即负载是均衡的。

&＃xff1a;要是数据库的架构做了主从同步&＃xff0c;读写分离&＃xff1a;写请求写主库&＃xff0c;读请求读从库也有可能导致缓存中进入脏数据呀&＃xff0c;这种情况怎么解决呢&＃xff08;读写请求根本不落在同一个DB上&＃xff0c;并且读写DB有同步时延&＃xff09;&＃xff1f;

&＃xff1a;下一篇文章和大家分享。