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