互联网大厂缓存与数据库的双写一致性解决方案-阿里云开发者社区

开发者社区> javaedge> 正文

互联网大厂缓存与数据库的双写一致性解决方案

简介: 互联网大厂缓存与数据库的双写一致性解决方案
+关注继续查看

用缓存,就会涉及到缓存与数据库双存储的双写,双写就一定会有数据一致性问题。


若系统不是严格要求缓存/数据库必须一致性,缓存可以稍微和数据库偶尔不一致,最好不要做双写。

读请求和写请求串行化,串到一个内存队列里去,这样就可以保证一定不会出现不一致。

串行化后,就会导致系统吞吐量骤降,就需要比正常情况下多几倍的机器去支撑线上环境请求。

Cache Aside Pattern缓存+数据库读写模式

  1. 读时,先读缓存,缓存没有,就读DB,然后取出数据后放入缓存,同时返回响应
  2. 更新时,先删缓存,再更新DB

为什么是删缓存,而不是更新缓存?

很多时候,复杂缓存场景,因为缓存有的时候,不单是DB中直接取出来的值。

比如商品详情页系统,修改库存,只是修改某表的某些字段,但要真正把影响的最终库存计算出,可能还需从其他表查询一些数据,进行一些运算,才能计出。

现在最新的库存是多少,然后才能将库存更新到缓存。


更新缓存的代价很高。

是不是每次修改DB,都必须更新对应缓存?

简单场景可以这样,但较复杂缓存数据计算场景,就不是了。


若你频繁修改一个缓存涉及的多个表,那么这个缓存会被频繁的更新,频繁的更新缓存


但问题在于,这个缓存到底会不会被频繁访问到?

比如,一个缓存涉及的表字段,在1min内就修改20次或100次,那么缓存更新20/100次;但该缓存在1min内就被读取了1次,有大量冷数据。


20%的数据,占用了80%的访问量。


若你只是删除缓存,那1min内,该缓存不过重新计算一次,开销大幅度降低。


每次请求过来,就只是删除缓存,然后修改DB,若该缓存在1min内只被访问1次,那么只有那1次缓存要被重新计算,需要用到缓存才去计算缓存。


删除缓存,而非更新缓存,也是一种惰性延迟计算思想,不要每次都重做复杂计算,不管它会不会用到,而是让它到需要被使用时再重新计算。


查询一个部门,部门带了一个员工的list,没必要每次查询部门,都把里面的1000个员工的数据也同时查出来。

80%的情况,查这个部门,就只是要访问这个部门的信息就可以了

先查部门,同时要访问里面的员工,那么这个时候只有在你要访问里面的员工的时候,才会去数据库里面查询1000个员工。

高并发场景下的缓存+数据库双写不一致

实时性比较高的数据缓存,就是库存服务。


库存可能会修改,每次修改都要去更新这个缓存数据; 每次库存的数据,在缓存中一旦过期,或者是被清理掉了,前端的nginx服务都会发送请求给库存服务,去获取相应的数据。

库存这一块,写数据库的时候,直接更新redis缓存。

数据库与缓存双写,数据不一致的问题

简单场景

  • 先修改数据库,再删除缓存
    如果缓存删除失败,那么会导致数据库是新数据,缓存是旧数据,数据不一致
  • 先删除缓存,再修改数据库
    如果删除缓存成功,修改数据库失败,那么数据库中是旧数据,缓存空,数据不会不一致。
    因为读时缓存没有,则读数据库中旧数据,然后更新到缓存。

复杂场景

数据发生变更,先删了缓存,然后要去修改DB,此时还没修改

一个请求突然过来,去读缓存,发现缓存空,转而去查询DB,查到修改前的旧数据,放入缓存。

数据变更的程序完成了数据库的修改。

结果,数据库和缓存中的数据不一致!

为什么高并发场景下,缓存会出现这问题?

只有在对一个数据在并发读写时,才可能会出现这种问题。

若每天上亿的流量,每秒几万QPS,每秒只要有数据更新请求,就可能会出现数据库+缓存不一致。

数据库 & 缓存更新与读取 异步串行化

更新数据的时候,根据数据的唯一标识,将操作路由之后,发送到一个JVM内部的队列中。


读数据的时候,如果发现数据不在缓存中,那么将重读数据+更新缓存,根据唯一标识路由之后,也发送同一个JVM内部的队列中。


一个队列对应一个工作线程。


每个工作线程串行拿到对应的操作,然后一条一条的执行。这样的话,一个数据变更的操作,先执行删除缓存,然后再更新数据库,但是还没完成更新。

此时如果一个读请求过来,读到了空缓存,则可以先将缓存更新的请求发送到队列中,此时会在队列中积压,然后同步等待缓存更新完成


一个队列中,其实多个更新缓存请求串在一起是没意义的,因此可以做过滤。如果发现队列中已经有一个更新缓存的请求了,那么就不用再放个更新请求操作进去了,直接等待前面的更新操作请求完成即可。


待那个队列对应的工作线程完成了上一个操作的数据库的修改之后,才会去执行下一个操作,也就是缓存更新的操作,此时会从数据库中读取最新的值,然后写入缓存中


  • 如果请求还在等待时间范围内,轮询发现可以取到值了,那么就直接返回
  • 如果请求等待的时间超过一定时长,那么这一次直接从数据库中读取当前的旧值

高并发场景下,该解决方案注意

读请求长时阻塞

由于读请求进行了轻度异步化,所以一定要注意读超时的问题,每个读请求必须在超时时间范围内返回


该解决方案,最大风险点在于,可能数据更新很频繁,导致队列中积压了大量更新操作,然后读请求会发生大量的超时,最后导致大量的请求直接走数据库


务必通过一些模拟真实的测试,看看更新数据的频繁是怎样的


另外一点,因为一个队列中,可能会积压针对多个数据项的更新操作,因此需要根据自己的业务情况进行测试,可能需要部署多个服务,每个服务分摊一些数据的更新操作


如果一个内存队列里居然会挤压100个商品的库存修改操作,每隔库存修改操作要耗费10ms区完成,那么最后一个商品的读请求,可能等待10 * 100 = 1000ms = 1s后,才能得到数据


这个时候就导致读请求的长时阻塞


一定要做根据实际业务系统的运行情况,去进行一些压力测试,和模拟线上环境,去看看最繁忙的时候,内存队列可能会挤压多少更新操作,可能会导致最后一个更新操作对应的读请求,会hang多少时间,如果读请求在200ms返回,如果你计算过后,哪怕是最繁忙的时候,积压10个更新操作,最多等待200ms,那还可以的


如果一个内存队列可能积压的更新操作特别多,那么你就要加机器,让每个机器上部署的服务实例处理更少的数据,那么每个内存队列中积压的更新操作就会越少


其实根据之前的项目经验,一般来说数据的写频率是很低的,因此实际上正常来说,在队列中积压的更新操作应该是很少的


针对读高并发,读缓存架构的项目,一般写请求相对读来说,是非常非常少的,每秒的QPS能到几百就不错了


一秒,500的写操作,5份,每200ms,就100个写操作


单机器,20个内存队列,每个内存队列,可能就积压5个写操作,每个写操作性能测试后,一般在20ms左右就完成


那么针对每个内存队列中的数据的读请求,也就最多hang一会儿,200ms以内肯定能返回了


写QPS扩大10倍,但是经过刚才的测算,就知道,单机支撑写QPS几百没问题,那么就扩容机器,扩容10倍的机器,10台机器,每个机器20个队列,200个队列


大部分的情况下,应该是这样的,大量的读请求过来,都是直接走缓存取到数据的


少量情况下,可能遇到读跟数据更新冲突的情况,如上所述,那么此时更新操作如果先入队列,之后可能会瞬间来了对这个数据大量的读请求,但是因为做了去重的优化,所以也就一个更新缓存的操作跟在它后面


等数据更新完了,读请求触发的缓存更新操作也完成,然后临时等待的读请求全部可以读到缓存中的数据


(2)读请求并发量过高

这里还必须做好压力测试,确保恰巧碰上上述情况的时候,还有一个风险,就是突然间大量读请求会在几十毫秒的延时hang在服务上,看服务能不能抗的住,需要多少机器才能抗住最大的极限情况的峰值


但是因为并不是所有的数据都在同一时间更新,缓存也不会同一时间失效,所以每次可能也就是少数数据的缓存失效了,然后那些数据对应的读请求过来,并发量应该也不会特别大


按1:99的比例计算读和写的请求,每秒5万的读QPS,可能只有500次更新操作


如果一秒有500的写QPS,那么要测算好,可能写操作影响的数据有500条,这500条数据在缓存中失效后,可能导致多少读请求,发送读请求到库存服务来,要求更新缓存


一般来说,1:1,1:2,1:3,每秒钟有1000个读请求,会hang在库存服务上,每个读请求最多hang多少时间,200ms就会返回


在同一时间最多hang住的可能也就是单机200个读请求,同时hang住


单机hang200个读请求,还是ok的

1:20,每秒更新500条数据,这500秒数据对应的读请求,会有20 * 500 = 1万

1万个读请求全部hang在库存服务上,就死定了

(3)多服务实例部署的请求路由

可能这个服务部署了多个实例,那么必须保证说,执行数据更新操作,以及执行缓存更新操作的请求,都通过nginx服务器路由到相同的服务实例上

(4)热点商品的路由问题,导致请求的倾斜

万一某个商品的读写请求特别高,全部打到相同的机器的相同的队列里面去了,可能造成某台机器的压力过大

就是说,因为只有在商品数据更新的时候才会清空缓存,然后才会导致读写并发,所以更新频率不是太高的话,这个问题的影响并不是特别大,但是的确可能某些机器的负载会高一些。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
快速构建大数据缓存
场景:          系统运行于正式环境后,发现时常发生OOM (OutOfMemory),通过 Windbg dump 了几个内存后发现很多缓存对象无法回收【分析过程另起新篇叙述】,于是想到如何处理缓存?   方案:          由于系统...
553 0
阿里云服务器怎么设置密码?怎么停机?怎么重启服务器?
如果在创建实例时没有设置密码,或者密码丢失,您可以在控制台上重新设置实例的登录密码。本文仅描述如何在 ECS 管理控制台上修改实例登录密码。
10062 0
使用OpenApi弹性释放和设置云服务器ECS释放
云服务器ECS的一个重要特性就是按需创建资源。您可以在业务高峰期按需弹性的自定义规则进行资源创建,在完成业务计算的时候释放资源。本篇将提供几个Tips帮助您更加容易和自动化的完成云服务器的释放和弹性设置。
12070 0
互联网广告行业逆势增长,数据湖解决方案成行业新解
阿里云面向金融行业,基于对象存储OSS构建了一个统一的数据湖。阿里云数据湖解决方案能够从各种数据源沉淀数据,将数据进行统一治理,并且可通过阿里云EMR集群,无缝对接各类计算引擎,展现数据最大化的价值。
2764 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,阿里云优惠总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系.
13875 0
互联网上云实践:场景化问题、解决方案和实战案例
为保证云栖大会质量,专场出品人都会做多方面的调研与内容准备,每场内容的设置都会充分考量当地参会者的实际需求,所以每场内容分享都有不同的侧重点。很多报名的朋友们希望能对日程、讲师以及参会建议能够有进一步的解读,云栖社区特别采访了分论坛出品人,为我们分享对于该场内容策划的思路,可以带来哪些有益的帮助。
4923 0
线上劳务派遣解决方案——亿网软通“互联网+产品”亿云销
线上劳务派遣解决方案——亿网软通“互联网+产品”亿云销
1787 0
阿里云推出全栈IPv6解决方案,加速推进下一代互联网应用
IPv4地址已接近枯竭,被誉为下一代互联网技术的IPv6成为新的“全球互联网门牌号”,它可以让地球上的每一粒沙子都拥有地址。
9288 0
+关注
javaedge
关注公众号:JavaEdge,后台回复面试,领取更多大厂求职资源。曾在百度、携程、华为等大厂搬砖,专注Java生态各种中间件原理、框架源码、微服务、中台等架构设计及落地实战,只生产硬核干货!
2315
文章
1
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载