spring 的接口和数据库查询有什么方法可以进行等待但不阻塞线程

[rockyou12]

现在有个业务，A 服务提供接口来对 iot 设备上的信息进行查询。但实际的查询流程是 A 调用 B 服务，B 服务去给 iot 设备发指令，然后 iot 的响应是异步返回通过其它服务写近了数据库。

所以 A 服务要在调用 B 后，又进行等待并查询数据库中是否有这条服务，这个过程由于暂时不知道设备的响应是何时返回的并写入完成的，所以一定要等待甚至进行重试。

我看了下 spring 的 controller 可以用 CompletableFuture 来做异步响应，这样不会阻塞 servlet 那里的 io，但查询数据的等待那里（也就是 future 的 callback ）除了 Thread.sleep 我好像想不到很好的等待方法。

用 redis 的 sub 或者类似的通知机制就算了，大幅加大了系统复杂度，暂时不考虑的

[yyyfor]

completableFuture 的 whenComplete 方法？

[vitoliu]

DefferedResult

[vitoliu]

DeferredResult

[royan]

你这已经是标准的异转同（异步转同步）方案了，即使引入消息通知机制也还要考虑被通知后如何唤醒当前这个业务线程（其实不太靠谱，参考分布式消息通知，被通知的都不一定是当前服务进程）。
如果对业务接口有控制权，不如考虑将当前业务接口调整为两个接口，一个负责接收业务指令，一个负责查询这个业务指令的执行结果。
即使对业务接口没有控制权，也建议增加一个负责查询业务指令执行结果的接口，谁能保证你那个同步等待不异常（比如超时，比如被 kill ）呢？

[rockyou12]

@vitoliu 你这和 Future 是一样的
@royan 其实我也想过给调用者一个 201，然后让对方自己去等待然后掉另外一个查询接口，但这样把复杂度暴露出去了，我不太喜欢

[RichardYyf]

这个不就是我最近刚做的一个需求吗，异步转同步，如果 A 调 B 和 iot 异步返回可以透传一个唯一性的 ID 的话，可以参考 Dubbo 的 DefaultFuture，我是简化了 Dubbo 那个类的设计，还没时间总结，楼主可以看下 https://juejin.im/post/5e5c4b6d51882549236f8233 这篇文章

[royan]

@rockyou12 理解。我是觉得 功能完整性 > 系统性能 > 设计优雅，类似微信统一支付也是单独提供一个查询接口来确保功能的最终完整性，同时避免了许多系统性能上的问题。