一、背景
在微服务框架下，跨服务之间的调用，当遇到操作耗时或者量大的情况，我们一般会采用异步编程实现。
本文出现的问题是：异步回调过来时，却未查询到数据库中的任务，导致未能正常处理回调。
下面是当时的日志信息：
根据此请求流水号查询数据库，得到入库时间：
总结下，产生这个错误的原因是数据库入库的时间晚于回调处理中查库的时间。
那么要如何避免这个问题呢？
有人可能要说，既然插入数据库的时间慢，是不是可以改为保存到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分钟，由主服务向外部服务发起主动查询。
这也是配套异步处理方案的常规处理动作。
比如交易系统里的支付操作，往往就需要商户主动向三方支付发起查询，询问支付中的订单状态其结果。
四、总结
异步编程，要求数据的一致性，往往采取的是最终一致性。
意味着在绝大多数情况下，实时回调可以保证数据更新的及时性，少数以及异常情况下，通过主动查询可以保证数据的最终一致性。
本案例中，主要是回调的速度快于本地数据库的入库，所以问题是少见的，一般也很难排查。