分布式系统:图解缓存与数据库一致性问题

前言

缓存设计是应用系统设计中重要的一环,是通过空间换取时间的一种策略,达到高性能访问数据的目的;但是缓存的数据并不是时刻存在内存中,当数据发生变化时,如何与数据库中的数据保持一致,以满足业务系统要求,本篇将给出具体分析。

一致性分类

  • 强一致性 :这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来的也会是什么,用户体验好,但实现起来往往对系统的性能影响大,这种情况比如秒杀系统,商家后台,他会设置秒杀商品,参与秒杀活动,一旦说他参与了秒杀活动,商品的库存本来是在数据库里的,此时必须直接被加载到缓存里,缓存立马就要可以被使用。
  • 弱一致性:这种一致性级别约束了系统在写入成功后,不承诺立即可以读到写入的值,也不承诺多久之后数据能够达到一致,但会尽可能地保证到某个时间级别(比如秒级别)后,数据能够达到一致状态
  • 最终一致性 :最终一致性是弱一致性的一个特例,系统会保证在一定时间内,能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来,是因为它是弱一致性中非常推崇的一种一致性模型,也是业界在大型分布式系统的数据一致性上比较推崇的模型,比如微博的粉丝数,页面每天的访问数

缓存更新机制

缓存的更新,一般分为被动更新与主动更新,被动更新是指缓存在有效期到后,被淘汰。

被动更新如下步骤:
step1: 发起方查数据,缓存中没有,从数据库中获取,并写入缓存,同时设置过期时间 t;
step2: 在 t 内,所有的查询,都由缓存提供,所有的写,直接写数据库;
step3: 当缓存数据到过期时间 t 后,缓存数据失效。后面的查询,回到了第 1 步。

主动更新,一般为调用方发起缓存与数据库同时更新,缓存分为删除、更新,数据库分为更新,通过组合与先后顺序,分为如下四种情况:
更新缓存、更新数据库更新数据库,更新缓存删除缓存,更新数据库更新数据库,删除缓存

更新缓存、更新数据库

这种情况,当缓存更新成功,数据库更新不成功时,数据不一致的风险比较高,所以一般不采用

更新数据库、更新缓存

当更新完数据库,缓存的加载前需要通过大量复杂计算才能得出缓存的值,不仅让发起方阻塞,影响性能;而且如果缓存命中率不高,很少使用,更浪费前期的复杂计算成本与缓存空间,这里就不符合懒加载的设计思想,故一般也不采用

删除缓存、更新数据库

如图所示,当两个调用方线程高并发访问的情况下,A 线程先删除缓存,再更新数据库,此过程时间较长,B 线程在 A 删除缓存后,迅速读取缓存,因缓存每命中,从数据库中读取再加载缓存,此时缓存还是旧值,等 A 线程更新完数据库后,发现又出现数据不一致的现象。

一般大概率情况下,出现此根源的原因是读比写快,所以这种一般也不采用,如果非得采用,需要在写完数据库之后延迟一段时间再删除一次缓存,也就是我们熟知的 延时双删,延迟多久呢,一般看数据库的更新时长来决定,此做法也会带来系统吞吐量下降

Cache-Aside

也叫做旁路缓存模式,流程就是先更新数据库,再删除缓存,虽然这种方式也会带来不一致的情况,比如如下场景:

前提:缓存无数据,数据库有数据。

A:查询,B:更新

过程如下:
step1: A 查缓存,无数据,去读数据库,旧值;
step2: B 更新数据库为新值;
step3: B 删除缓存;
step4: A 将旧值写入缓存。

该场景最终也会出现不一致,产生的根源是是读比写慢,这种是小概率事件,一般很少出现,如果非要解决这种情况,还是上面说的延迟双删

Read/Write Through

上面的方式,数据库是缓存的来源,主导是数据库,而 Read/Write Through模式,相当于缓存占主导。在 cache-aside 模式中,我们的应用代码需要维护两个数据存储,一个是缓存(Cache),一个是数据库(Repository)。而 Read/Write Through 做法是把更新数据库(Repository)的操作由缓存自己代理了,所以,对于应用层来说,就简单很多了。可以理解为,应用认为后端就是一个单一的存储,而存储自己维护自己的 Cache。

Read Through

Read Through 就是在查询操作中更新缓存,也就是说,当缓存失效的时候(过期或 LRU 换出),Cache Aside 是由调用方负责把数据加载入缓存而 Read Through 则用缓存服务自己来加载,从而对应用方是透明的

这个简要流程和 Cache-Aside 很像,其实Read-Through 就是多了一层Cache-Provider,流程如下:

Read-Through 实际只是在Cache-Aside之上进行了一层封装,它会让程序代码变得更简洁,同时也减少数据源上的负载

Write Through

Write Through,和 Read Through 相仿,不过是在更新数据时发生。当有数据更新的时候,如果没有命中缓存,直接更新数据库,然后返回。如果命中了缓存,则更新缓存,然后再由 Cache 自己同步更新数据库

值得注意的是,该方案在实现过程中,程序启动时,需将数据库的数据, 提前放到缓存中,不能等启动完成,再放缓存中。

Read Through/Write Through 策略的特点是由缓存节点而非应用程序来和数据库打交道,在我们开发过程中相比 Cache Aside 策略要少见一些,原因是我们经常使用的分布式缓存组件,无论是 Memcached 还是 Redis 都不提供写入数据库和自动加载数据库中的数据的功能。而我们在使用本地缓存的时候可以考虑使用这种策略。

Write Behind

Write Behind 又叫 Write Back。底层思想就是在更新数据的时候,只更新缓存,不更新数据库,而我们的缓存会异步地批量更新数据库。这个设计的好处就是让数据的 I/O 操作速度飞快(因为是直接操作内存),同时带来吞吐量大幅上升;因为异步,Write Behind 还可以合并对同一个数据的多次操作,所以性能的提高是相当可观的。

但是,其带来的问题是,数据不是强一致性的 ,而且可能会丢失(我们知道 Unix/Linux 非正常关机会导致数据丢失,就是因为这个事)。在软件设计上,我们基本上不可能做出一个没有缺陷的设计,就像算法设计中的时间换空间,空间换时间一个道理,有时候,强一致性和高性能,高可用和高性性是有冲突的。如果说软件功能模块的思维是逻辑与实现,那么软件架构设计的思维是权衡与取舍

这种方式下,缓存和数据库的一致性不强,对一致性要求高的系统要谨慎使用 。但是它适合频繁写的场景,MySQL 的InnoDB Buffer Pool 机制就使用到这种模式。

Write Behind 实际应用

按照实际架构应用层面落地参考方案,流程图如下(以用户发表视频为例)

按照这种方案,正常来说只要 10 分钟内数据正常写完就没问题,可以实现最终一致性,但是一旦超出 10 分钟,就会缓存失效,造成缓存不一致

如果出现这种 kafka 消费入库失败,则会触发报警系统,看具体是什么问题,基本上 kaka 入库失败只有两种情况,一种是出错了,另外一种是消费能力不够,那么直接扩容即可

后记

说到底这个问题根本没有通用方案,需要根据场景做权衡,比如类似于微博这样高并发场景,那么上边只要涉及删除缓存的方案基本都很难实现,因为很可能删除缓存的下一时间热点数据直接全部打在数据库上,整个服务直接崩溃

然后本质上缓存和数据库的更新就不是一个原子操作,想要彻底实现强一致性,可以了解下分布式事务或是其他强一致性协议,比如说两阶段提交协议 ------ prepare, commit/rollback,比如 Java 7 的 XAResource,还有 MySQL 5.7 的 XA Transaction,有些 cache 也支持 XA,比如 EhCache

参考链接

本文由博客一文多发平台 OpenWrite 发布!

相关推荐
也无晴也无风雨31 分钟前
深入剖析输入URL按下回车,浏览器做了什么
前端·后端·计算机网络
斑驳竹影3 小时前
【RabbitMQ】之高可用集群搭建
分布式·rabbitmq
2401_857610034 小时前
多维视角下的知识管理:Spring Boot应用
java·spring boot·后端
代码小鑫4 小时前
A027-基于Spring Boot的农事管理系统
java·开发语言·数据库·spring boot·后端·毕业设计
Ztiddler4 小时前
【Linux Shell命令-不定期更新】
linux·运维·服务器·ssh
floret*4 小时前
Kafka高频面试题详解
分布式·kafka
小小不董4 小时前
Oracle OCP认证考试考点详解082系列16
linux·运维·服务器·数据库·oracle·dba
Wlq04155 小时前
分布式技术缓存技术
分布式·缓存
IPdodo全球网络5 小时前
如何利用静态住宅IP优化Facebook商城的网络稳定性与运营效率
运维·服务器
明达技术5 小时前
LVDS高速背板总线:打造分布式I/O高效数据传输新境界
分布式·物联网·自动化·lvds