微服务框架,Http异步编程中,如何保证数据的最终一致性

一、背景

在微服务框架下,跨服务之间的调用,当遇到操作耗时或者量大的情况,我们一般会采用异步编程实现。

本文出现的问题是:异步回调过来时,却未查询到数据库中的任务,导致未能正常处理回调。

下面是当时的日志信息:

根据此请求流水号查询数据库,得到入库时间:

总结下,产生这个错误的原因是数据库入库的时间晚于回调处理中查库的时间。

那么要如何避免这个问题呢?

有人可能要说,既然插入数据库的时间慢,是不是可以改为保存到redis呢?

要保证请求流水号存在,不一定要入库(redis也是为了实现插入快),所以我建议把它保存在jvm内存缓存中(具体实现可以是Map集合,也可以是caffeine)。

但是遇到生产环境分布式环境下,主服务是多节点部署的情况下,这个并不能解决问题。

所以还是调整代码的顺序,先入库,再发起http请求。(尽可能地做到先入库,实在不行,延迟1秒后再发起http请求)

当然,为了数据的实时性,不建议增加延时调用。因为这是偶现的极端情况。

二 、系统设计

如果外部服务从接收请求,到回调主服务,这个过程只有几十毫秒;也就是说,主服务收到外部服务的回调,是早于主服务把任务持久化到DB,在处理回调的时候,根据请求流水号无法查询到任务详情。

在极端的情况下,便出现了如下异常流程:

三、如何保证查询

要解决上面的异常流程,可以采用以下几种办法:

  • 1、先保存任务表,再发起http请求。
  • 2、在收到外部服务的回调后,第一时间未查询到,则查询第二次,第三次...... 尝试多次查询,等待保存任务表的插入语句操作完成。
  • 3、主服务向外部服务发起主动查询操作结果。(外部服务提供一个根据请求流水号查询详情的接口)

1、调整发起请求的代码顺序

java 复制代码
// 先保存至本地缓存
requestNoService.saveCache(requestNo, gson.toJson(request));

// 保存至定时任务表
NotifyTasks notifyTasks = notifyTasksService.schedule(Constants.TaskCode.QUERY_CLASSROOM_COPY_RESULT, requestNo,
        assemblerCopyResultRequestUrl(requestNo), gson.toJson(request));

// 再发起复制请求,避免出现回调收到了,但是本地表中没有数据,导致回调失败。
ApiResult<?> apiResult = notifyTasksService.notify(taskCode, notifyTasks.getRequestNo(),
        urlBuilder.toString(), gson.toJson(request));

修改前的代码:

java 复制代码
// 发起复制请求
ApiResult<?> apiResult = notifyTasksService.notify(taskCode, requestNo, urlBuilder.toString(), gson.toJson(request));

// 保存至定时任务表
notifyTasksService.schedule(Constants.TaskCode.CLASSROOM_COPY_RESULT, requestNo,
        assemblerCopyResultRequestUrl(requestNo), gson.toJson(request));

2、多次延迟查询

重试3次,每次延迟1秒后再发起查询

java 复制代码
	private String getNotifyParamsFromDB(String requestNo) {
        int attempt = 0;

        while (attempt < 3) {
            NotifyTasks notifyTasks = notifyTasksRepository.findTop1ByRequestNo(requestNo);
            if (null != notifyTasks) {
                return notifyTasks.getNotifyParams();
            }

            ThreadUtil.sleep(1, TimeUnit.SECONDS);

            attempt++;
        }

        return null;
    }

3、发起主动查询

定时任务,每隔5分钟,由主服务向外部服务发起主动查询。

这也是配套异步处理方案的常规处理动作。

比如交易系统里的支付操作,往往就需要商户主动向三方支付发起查询,询问支付中的订单状态其结果。

四、总结

异步编程,要求数据的一致性,往往采取的是最终一致性。

意味着在绝大多数情况下,实时回调可以保证数据更新的及时性,少数以及异常情况下,通过主动查询可以保证数据的最终一致性。

本案例中,主要是回调的速度快于本地数据库的入库,所以问题是少见的,一般也很难排查。

相关推荐
杨DaB6 分钟前
【SpringMVC】MVC中Controller的配置 、RestFul的使用、页面重定向和转发
java·笔记·后端·学习·spring·mvc·restful
linyb极客之路10 分钟前
干货来袭!5 分钟学会快速实现责任链,效率直接拉满!
java
创码小奇客14 分钟前
保姆级 Talos 超参数优化实战指南:从入门到封神
java·后端·架构
程序媛李李李李李蕾20 分钟前
你不能直接用现成的吗?整个前端做笔记管理工具真是折腾人
javascript·vue.js·后端
青云交22 分钟前
Java 大视界 -- Java 大数据在智能安防入侵检测系统中的多源数据融合与误报率降低策略(369)
java·大数据·入侵检测·智能安防·多源数据融合·误报率降低·视频语义理解
易元30 分钟前
设计模式-访问者模式
前端·后端·设计模式
我会冲击波33 分钟前
告别手写注释!变量命名、注释IDEA插件更新了,AI帮你搞定一切代码注释
java·intellij idea
liangdabiao41 分钟前
一篇文章尽快介绍入门级智能体Agent是什么回事, Starter AI Agents 项目 来自 awesome-llm-apps
前端·后端
BUG创建者1 小时前
openlayer根据不同的状态显示不同的图层颜色
android·java·javascript
JohnYan1 小时前
工作笔记 - 一种业务信息汇报机制的设计和实现
数据库·后端·postgresql