接口异步回调

接口异步回调

有些接口,内部逻辑非常复杂,非常耗时。

可以通过接口异步回调来实现,避免超时。

比如 , 系统A 的 A1接口调用 系统B 的 B1接口, 系统B在完成功能后,系统B 回调系统A 的 另一个接口 A2。

小心第三方系统不回调

一定要做主动查询 。如果第三方系统不回调,也能通过主动查询,根据查询结果触发逻辑。

可以先在数据表插入数据,再调用第三方系统的接口

如果系统A 需要在数据表插入数据, 最好先插数据,再调用 系统 B,最后根据回调结果更新数据表。

如果先调用系统 B,有可能系统 B 回调太快, 系统 A的数据表还没插入成功,导致数据没有更新成功。

调用第三方系统,以及接收第三方系统的回调,最好打日志

如果调用第三方系统,以及接收第三方系统的回调时,没有日志,那发生问题时,不好排查。

打印日志,出现问题时,可以向第三方系统提供url、入参、出参。

第三方系统回调和主动查询同时发生,注意并发更新的问题

可以通过 mysql的乐观锁 来保证幂等性。

比如 只有当 订单状态是未支付时,才更新为 支付成功。这样能够避免业务逻辑重复执行。

第三方系统回调是否需要终止回调、减少重复回调

有些系统会要求在逻辑成功后,终止回调。

比如逻辑更新成功,返回一个特定的响应码code,这样第三方系统就不再回调了。

执行逻辑成功后终止回调,可以减少对系统的网络连接,节省系统的资源。

posted on   乐之者v  阅读(28)  评论(0编辑  收藏  举报

相关博文:
阅读排行:
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· DeepSeek 开源周回顾「GitHub 热点速览」
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

导航

统计

点击右上角即可分享
微信分享提示