微服务框架,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分钟,由主服务向外部服务发起主动查询。

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

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

四、总结

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

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

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

相关推荐
极客悟道8 分钟前
颠覆传统虚拟化:在Docker容器中运行Windows系统的开源黑科技
前端·后端
调试人生的显微镜35 分钟前
WebView 中 Cookie 丢失怎么办?跨域状态不同步的调试与修复经验
后端
weixin_437398211 小时前
转Go学习笔记(2)进阶
服务器·笔记·后端·学习·架构·golang
极客悟道1 小时前
巧解 Docker 镜像拉取难题:无需梯子和服务器,拉取数量无限制
后端·github
代码的余温1 小时前
5种高效解决Maven依赖冲突的方法
java·maven
慕y2741 小时前
Java学习第十六部分——JUnit框架
java·开发语言·学习
DavidSoCool1 小时前
RabbitMQ使用topic Exchange实现微服务分组订阅
分布式·微服务·rabbitmq
paishishaba1 小时前
Maven
java·maven
aiopencode1 小时前
iOS 出海 App 安全加固指南:无源码环境下的 IPA 加固与防破解方法
后端
liangdabiao1 小时前
AI一人公司?先搞定聚合支付!一天搞定全能的聚合支付系统
后端