• 缓存与数据库双写一致性几种策略分析


    一、背景

    在高并发场景中,为防止大量请求直接访问数据库,缓解数据库压力,常用的方式一般会增加缓存层起到缓冲作用,减少数据库压力。引入缓存,就会涉及到缓存与数据库中数据如何保持一致性问题,本文将对几种缓存与数据库保证数据一致性的使用方式进行分析。为保证高并发性能,以下分析场景不考虑执行的原子性及加锁等强一致性要求的场景,仅追求最终一致性。

    二、读取过程

    

    

    •读缓存

    •如果缓存里没有值,那就读取数据库的值

    •同时把这个值写进缓存中


    

    三、更新过程

    更新操作有多种策略,各有优劣,主要针对此场景进行分析

    策略1:先更新db,再删除缓存(常用的Cache-Aside Pattern旁路缓存)

    

    

    问题:

    1.如果更新db成功,删缓存失败,将导致数据不一致

    2.极端场景,请求A读,B写

    1)此时缓存刚好失效 2)A查库得到旧值 3)B更新DB成功

    4)B删除缓存 5)A将查到的旧值更新到缓存中

    此场景的发生需要步骤2)查db 始终慢于 3)的更新db,才能导致4)先于5)执行,通常db的查询是要快于写入的,所以此极端场景的产生过于严格,不易发生

    策略2:先更新db,再更新缓存

    

    

    问题:

    1.并发更新场景下,更新缓存会导致数据不一致

    2.根据读写比,考虑是否有必要频繁同步更新缓存,而且,如果构造缓存中数据过于复杂,或者数据更新频繁,但是读取并不频繁的情况,还会造成不必要的性能损耗

    此种方式不推荐


    

    策略3:先更新缓存,再更新db

    

    

    同上,不推荐


    

    策略4:先删缓存,再更新db

    

    

    先删缓存,虽然解决了策略1中,后删缓存如果失败的场景,但也会发生不一致的问题

    例如:请求 A 删除缓存,这时请求B来查,就会击穿到数据库,B读取到旧的值后写入缓存,A正常更新db,由于时间差导致数据不一致的情况


    

    策略5:缓存延时双删

    

    

    该策略兼容了策略1和策略4,解决了先删缓存还是后删缓存的问题,如策略1中,更新db后删缓存失败和策略4中的不一致场景,该策略可以将延时时间内(比如延时10ms)所造成的缓存脏数据,再次删除。但是,如果延时删缓存失败,策略4中不一致问题还会发生,同时延时的实现,如创建线程,或者引入mq异步,可能会增加系统复杂度问题。

    


    

    

    策略6:变种双删,前置缓存过期时间

    

    

    该策略针对策略1中后删缓存失败的场景,前置一层缓存数据过期时间(具体时间根据自身系统本身评估,如可覆盖db读写耗时或一致性容忍度等),更新db后就算删缓存失败,在expire时间后也能保证缓存中无数据。同时,前置expire失败,或者更新db失败,都不会影响数据一致。

    能够解决策略4中的问题:请求 A 删除缓存,这时请求B来查,就会击穿到数据库,B读取到旧的值后写入缓存,A正常更新db,由于时间差导致数据不一致的情况,描述图如下:

    

    

    本策略中步骤1为expire缓存,不会发生击穿缓存到数据库的情况,数据将直接返回。除非更极端情况,如下图:

    expire时间没有覆盖住更新db的耗时,类似策略1中极端场景,此处不赘述

    

    

    四、总结

    对于每种方案策略,各有利弊,但一致性问题始终存在(文章开头排除了原子性和锁),只是发生的几率在一点点慢慢变小了,方案的评估不仅要根据自身系统的业务场景,如读写比、并发量、一致性容忍度,还要考虑系统复杂度,投入产出比等,寻找最合适的方案。

  • 相关阅读:
    那么多SSM框架整合,这篇用心整理的SSM框架笔记不会还有程序员没看过吧?
    【软考】系统集成项目管理工程师(六)项目整体管理【6分】
    GnuTLS recv error (-110): The TLS connection was non-properly terminated
    SpringMvc进阶
    jwt判断解析失败还是令牌过期
    ide 插件推荐
    基于ArcGIS进行空间方向性研究
    【吞噬星空4】又魔改,徐欣自杀殉情,变成被阿特金击杀,引发粉丝吐槽
    postgresql模糊查询(like和~)引用变量
    云原生kubernetes从入门到实践系列教程
  • 原文地址:https://blog.csdn.net/fuqianming/article/details/134328175