数据一致性问题的相关案例及解决方案

项目场景:

简述项目相关背景:

调用外部系统的一个接口,这个接口是更新单据状态的接口。现在外部这个接口执行需要一定时间,我调用了这个接口之后,立马异步查询这个单据的状态。最终导致状态不一致的问题


问题描述

这个问题属于并发控制数据一致性问题。具体来说,当你调用外部接口更新单据状态后,立即发起异步查询,由于网络延迟接口处理时间以及数据库的ACID特性(特别是隔离性),你可能会观察到不一致的结果。这种情况在分布式系统中很常见。


原因分析:

提示:这里填写问题的分析:

外部系统架构可能采用消息队列的方式,或者外部系统吞吐量较大,导致接口响应慢。


解决方案:

从目标出发,从数据一致性原则出发,主要有两种解决方案:

1、强一致性:同步(但是不行,如果外部系统采用消息队列异步的情况。获取的返回结果没有参考意义)

2、最终一致性:还是采取异步的方式。但是需要添加补足策略保证数据状态的最终一致性。

下面是一些保证最终一致性的补足策略方式:

1、延迟查询:

可以设定一个合理的延时(例如使用delay或sleep函数)后再发起查询,给外部系统足够的时间去完成状态更新。
2、幂等性设计:(强一致性方案)

使接口幂等,即多次调用同一个接口,结果始终相同。这样即使查询早于更新完成,再次查询也会得到正确的结果。
3、使用事务和两阶段提交(2PC):

如果外部系统支持,可以使用两阶段提交协议来确保更新和查询都在一个事务内完成,保证数据一致性。
4、回查机制:

不立即查询状态,而是约定一个时间点或者在用户触发特定操作时再进行状态查询,如果查询结果不一致,可以设定一个回查机制,定时重试查询直到状态正确。
5、版本号或乐观锁:(当前情景不适用)

给单据添加一个版本号字段,每次更新时检查当前版本号是否与预期一致,如果不一致则表示有其他更新操作,需要重新尝试。
6、补偿操作:

如果查询到的状态不正确,可以设计补偿操作,比如记录不一致情况,然后通过后台任务来修正。
7、异步确认:

外部系统在完成状态更新后,通过回调或消息队列通知你的系统,确保在接收到确认后再进行后续操作。

选择择哪种方法取决于系统架构、性能要求和外部系统的特性。通常,结合业务场景和系统设计,可以采取一种或多种策略来确保数据一致性。所以,从当前系统架构时间成本技术成本出发选择回查机制实现数据的最终一致性。

相关推荐
一个天蝎座 白勺 程序猿31 分钟前
飞算JavaAI进阶:重塑Java开发范式的AI革命
java·开发语言·人工智能
前端 贾公子34 分钟前
tailwindCSS === 使用插件自动类名排序
java·开发语言
没有bug.的程序员40 分钟前
JAVA面试宝典 -《Spring Boot 自动配置魔法解密》
java·spring boot·面试
Bug退退退1231 小时前
RabbitMQ 之消息积压
分布式·rabbitmq
熊猫钓鱼>_>1 小时前
Hadoop 用户入门指南:驾驭大数据的力量
大数据·hadoop·分布式
hnlucky1 小时前
《Nginx + 双Tomcat实战:域名解析、静态服务与反向代理、负载均衡全指南》
java·linux·服务器·前端·nginx·tomcat·web
hnlucky1 小时前
同时部署两个不同版本的tomcat要如何配置环境变量
java·服务器·http·tomcat·web
yngsqq2 小时前
netdxf—— CAD c#二次开发之(netDxf 处理 DXF 文件)
java·前端·c#
A了LONE2 小时前
h5的底部导航栏模板
java·前端·javascript
经典19923 小时前
spring boot 详解以及原理
java·spring boot·后端