缓存与数据库一致性优化.pdfVIP

缓存与数据库⼀致性优化 本⽂主要讨论这么⼏个问题： （1）啥时候数据库和缓存中的数据会不⼀致 （2 ）不⼀致优 思路 （3 ）如何保证数据库与缓存的⼀致性 ⼀、需求缘起 上⼀篇 《缓存架构设计细节⼆三事》 （点击查看）引起了⼴泛的讨论，其中有⼀个结 论：当数据发⽣变 时，“先淘汰缓存，再修改数据库”这个点是⼤家讨论的最多的。 上篇⽂章得出这个结论的依据是，由于操作缓存与操作数据库不是原⼦的，⾮常有可 能出现执⾏失败。 假设先写数据库，再淘汰缓存：第⼀步写数据库操作成功，第⼆步淘汰缓存失败，则 会出现DB 中是新数据，Cache 中是旧数据，数据不⼀致 【如上图：db 中是新数据， cache 中是旧数据】。 假设先淘汰缓存，再写数据库：第⼀步淘汰缓存成功，第⼆步写数据库失败，则只会 引发⼀次Cache miss 【如上图：cache 中⽆数据，db 中是旧数据】。 结论：先淘汰缓存，再写数据库。 引发⼤家热烈讨论的点是“先操作缓存，在写数据库成功之前，如果有读请求发⽣， 可能导致旧数据⼊缓存，引发数据不⼀致” ，这就是本⽂要讨论的主题。 ⼆、为什么数据会不⼀致 回顾⼀下上⼀篇⽂章中对缓存、数据库进⾏读写操作的流程。 写流程： （1）先淘汰cache （2 ）再写db 读流程： （1）先读cache ，如果数据命中hit则返回 （2 ）如果数据未命中miss则读db （3 ）将db 中读取出来的数据⼊缓存 什么情况下可能出现缓存和数据库中数据不⼀致呢？ 在分布式环境下，数据的读写都是并发的，上游有多个应⽤，通过⼀个服务的多个部 署 （为了保证可⽤性，⼀定是部署多份的），对同⼀个数据进⾏读写，在数据库层⾯ 并发的读写并不能保证完成顺序，也就是说后发出的读请求很可能先完成 （读出脏数 据）： （a ）发⽣了写请求A ，A的第⼀步淘汰了cache （如上图中的1） （b ）A的第⼆步写数据库，发出修改请求 （如上图中的2 ） （c ）发⽣了读请求B ，B的第⼀步读取cache ，发现cache 中是空的 （如上图中的步骤 3 ） （d ）B的第⼆步读取数据库，发出读取请求，此时A 的 ⼆步写数据还没完成，读出 了⼀个脏数据放⼊cache （如上图中的步骤4 ） 即在数据库层⾯，后发出的请求4 ⽐先发出的请求2先完成了，读出了脏数据，脏数据 又⼊了缓存，缓存与数据库中的数据不⼀致出现了 三、不⼀致优化思路 能否做到先发出的请求⼀定先执⾏完成呢？常见的思路是“ 串⾏ ” ，今天将和⼤家⼀ 起探讨“ 串⾏ ”这个点。 先⼀起细看⼀下，在⼀个服务中，并发的多个读写SQL⼀般是怎么执⾏的 上图是⼀个service服务的上下游及服务内部详细展开，细节如下： （1）service的上游是多个业务应⽤，上游发起请求对同⼀个数据并发的进⾏读写操 作，上例中并发进⾏了⼀个uid= 1的余额修改 （写）操作与uid= 1的余额查询 （读）操 作 （2 ）service的下游是数据库DB ，假设只读写⼀个DB （3 ）中间是服务层service ，它又分为了这么⼏个部分 （3.1）最上层是任务队列 （3.2 ）中间是⼯作线程，每个⼯作线程完成实际的⼯作任务，典型的⼯作任务是 通过数据库连接池读写数据库 （3.3 ）最下层是数据库连接池，所有的SQL语句都是通过数据库连接池发往数据 库去执⾏的 ⼯作线程的典型⼯作流是这样的： void wor _thread_routine(){ Tas t = Tas Queue .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条数据库连接