小当家ISV
互联网高新技术服务商

全球共有10多个国家和地区1000多个平台,20万+商户使用

Redis数据一致性

作者:    郭朝兵       发布时间:     2024-06-07          168      分类专栏: 后端开发

1、一致性

一致性是指系统中各节点数据保持一致。分布式系统中,可以理解为多个节点中的数据是一致的。

一致性根据严苛程度分类:

强一致性:写进去的数据是什么,读出来的数据就是什么,对性能影响最大;

弱一致性:数据写入成功后,系统不保证能立刻读出最新的数据,也不承诺多久之后数据可以达到一致,但保证到某个时间级别后,数据能达到一致;

最终一致性:最终一致性是弱一致性的一个特例,最终一致性同样只保证数据写入成功后,在某个时间点后数据会达到一致。这个系统无法保证强一致性的时间片段被称为不一致窗口。不一致时间窗口的时间长短取决于很多因素,比如副本个数、网络延迟、系统负载等。

最终一致性是弱一致性中非常受大众推崇的一种一致性模型,也是目前业界在大型分布式系统的数据一致性上比较推崇的模型。

2、缓存使用场景

对于大部分系统而言,高并发常见于读数据的场景,对于此场景我们可以使用缓存提升数据查询速度。当我们使用Redis作缓存的时候,常见场景如下所示:

缓存存在

如果数据在缓存中存在,则直接从缓存返回数据至应用,无需查询数据库

 001.jpeg

缓存不存在

如果数据在缓存中不存在,则需查询数据库获取数据并更新缓存。

 002.jpeg

对于大部分系统而言最终数据都会存储在数据库中,也就是系统需已数据库中数据为准,那么对于上图缓存存在的场景下,当数据库中的数据发生变化时,就可能会出现数据不一致的问题。

实际情况下考虑网络、操作、异常等种种因素,根本无法保证可以同时更新所有副本数据使得数据保持一致。因此,如何在最大程度上保证各副本数据一致的同时也不影响系统性能,成了各系统需要均衡的问题。

3、数据同步策略

为保证缓存数据与数据库数据一致,主要考虑如下两种策略实现:

1、先删除缓存,再更新数据库;

2、先更新数据库,再删除缓存;

当然除了这两种策略之外,还有其他策略如将删除缓存改为更新缓存,但考虑高频繁更新及热冷数据场景下缓存使用效率问题,个人不推荐更新缓存方式,所以此处不做展开。

3.1 先删除缓存,在更新数据库

操作流程如图

003.jpeg

如上图,若先删除缓存,再更新数据库,则可能存在如下问题:

若步骤5、6、7顺序发生在步骤3、4之前或步骤3更新失败,则步骤8中线程B查询出的数据为旧数据,导致重新写入缓存的也为旧数据。

3.1.1 解决思路

失败重试 + 延时双删

004.jpeg

如图中红色部分所述,线程A在步骤4数据更新成功后,延迟一段时间,再次删除缓存,这样即可解决并发场景下线程B并发操作导致缓存与数据库数据不一致问题。延迟时间视实际业务场景对时间敏感度而定。

 3.2 先更新数据库,再删除缓存

操作流程如图

005.jpeg

如上图,若先更新数据库,再删除缓存,则可能存在如下问题:

步骤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

所属分类: 后端开发
京东回应「磨铁抵制京东」;苹果被骗近8700万元。

小当家,帮您把生意越做越大!

小当家ISV,重庆APP开发,小程序开发,软件系统开发 地址:重庆市南岸区南坪万达广场写字楼2栋19-6 联系电话:023-81361879

ICP备案号:渝ICP备15003473-1 增值电信业务许可证: 渝B2-15003473 渝公网安备 50010802005103号

友情链接: APP定制开发  小程序定制开发  MagicShop商城系统  酒类行业解决方案 

重庆小当家互联网信息技术有限公司