当前位置：首页 > news >正文

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

news 2025/7/3 9:30:26

一、背景

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

本文出现的问题是：异步回调过来时，却未查询到数据库中的任务，导致未能正常处理回调。
在这里插入图片描述

下面是当时的日志信息：
在这里插入图片描述
根据此请求流水号查询数据库，得到入库时间：

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

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

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

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

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

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

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

二、系统设计

在这里插入图片描述

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

在极端的情况下，便出现了如下异常流程：
在这里插入图片描述

三、如何保证查询

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

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

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

// 先保存至本地缓存
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));

修改前的代码：

// 发起复制请求
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秒后再发起查询

	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;}