全球共有10多个国家和地区1000多个平台,20万+商户使用
Redis数据一致性
作者: 郭朝兵 发布时间: 2024-06-07 409 分类专栏: 后端开发
1、一致性
一致性是指系统中各节点数据保持一致。分布式系统中,可以理解为多个节点中的数据是一致的。
一致性根据严苛程度分类:
强一致性:写进去的数据是什么,读出来的数据就是什么,对性能影响最大;
弱一致性:数据写入成功后,系统不保证能立刻读出最新的数据,也不承诺多久之后数据可以达到一致,但保证到某个时间级别后,数据能达到一致;
最终一致性:最终一致性是弱一致性的一个特例,最终一致性同样只保证数据写入成功后,在某个时间点后数据会达到一致。这个系统无法保证强一致性的时间片段被称为不一致窗口。不一致时间窗口的时间长短取决于很多因素,比如副本个数、网络延迟、系统负载等。
最终一致性是弱一致性中非常受大众推崇的一种一致性模型,也是目前业界在大型分布式系统的数据一致性上比较推崇的模型。
2、缓存使用场景
对于大部分系统而言,高并发常见于读数据的场景,对于此场景我们可以使用缓存提升数据查询速度。当我们使用Redis作缓存的时候,常见场景如下所示:
缓存存在
如果数据在缓存中存在,则直接从缓存返回数据至应用,无需查询数据库
缓存不存在
如果数据在缓存中不存在,则需查询数据库获取数据并更新缓存。
对于大部分系统而言最终数据都会存储在数据库中,也就是系统需已数据库中数据为准,那么对于上图缓存存在的场景下,当数据库中的数据发生变化时,就可能会出现数据不一致的问题。
实际情况下考虑网络、操作、异常等种种因素,根本无法保证可以同时更新所有副本数据使得数据保持一致。因此,如何在最大程度上保证各副本数据一致的同时也不影响系统性能,成了各系统需要均衡的问题。
3、数据同步策略
为保证缓存数据与数据库数据一致,主要考虑如下两种策略实现:
1、先删除缓存,再更新数据库;
2、先更新数据库,再删除缓存;
当然除了这两种策略之外,还有其他策略如将删除缓存改为更新缓存,但考虑高频繁更新及热冷数据场景下缓存使用效率问题,个人不推荐更新缓存方式,所以此处不做展开。
3.1 先删除缓存,在更新数据库
操作流程如图
如上图,若先删除缓存,再更新数据库,则可能存在如下问题:
若步骤5、6、7顺序发生在步骤3、4之前或步骤3更新失败,则步骤8中线程B查询出的数据为旧数据,导致重新写入缓存的也为旧数据。
失败重试 + 延时双删
如图中红色部分所述,线程A在步骤4数据更新成功后,延迟一段时间,再次删除缓存,这样即可解决并发场景下线程B并发操作导致缓存与数据库数据不一致问题。延迟时间视实际业务场景对时间敏感度而定。
操作流程如图
如上图,若先更新数据库,再删除缓存,则可能存在如下问题:
步骤5、6发生在步骤3之前或步骤3删除缓存失败,则线程B通过步骤5会拿到缓存数据,但此时获取到的缓存数据仍为旧数据。
3.2.1 解决思路
订阅binlog
数据库的每一步操作均会写入binlog日志,可以通过监听binlog,实时感知数据变化情况,根据数据变化情况删除redis并添加重试机制,直至redis删除成功。
引入消息队列
上图步骤3中若Redis删除失败,则将Redis key放入消息队列,消费端监听消息队列并删除Redis直至删除成功;
4 总结
需要注意的是3.1.1 和 3.2.1中描述的解决方案也只能保证最终数据一致性,无法保证强一致性,如上述各场景中若线程A操作异常,在通过3.1.1 和 3.2.1的方式解决问题之前,其他线程仍有可能获取到脏数据。
原文链接:https://blog.csdn.net/sxg0205/article/details/127531279
郭朝兵
小当家ISV,重庆APP开发,小程序开发,软件系统开发 地址:重庆市南岸区南坪万达广场写字楼2栋19-6 联系电话:023-81361879
ICP备案号:渝ICP备15003473-1 增值电信业务许可证:
渝B2-15003473
渝公网安备 50010802005103号
友情链接: APP定制开发 小程序定制开发 MagicShop商城系统 酒类行业解决方案
重庆小当家互联网信息技术有限公司