依赖回调返回结果的同步REST API端点实现方案咨询

你最初考虑的「异步线程+轮询单例Map」的思路不推荐，存在几个硬伤：CPU轮询空转浪费资源、非线程安全的Map在并发下会出脏读/死循环问题、没有超时兜底容易把请求线程挂死、多实例部署时状态完全不互通。

核心实现逻辑（通用，不绑定特定技术栈） #

核心是用阻塞等待/唤醒机制替代轮询，零CPU空转，完全匹配你要的同步返回要求，流程如下：

• 客户端请求打到/foo端点时，先生成全局唯一请求ID（UUID/雪花ID都可以），把这个ID透传给下游业务系统，下游触发回调时必须带回这个ID做关联
• 为当前请求创建一个支持超时的等待原语（Java用CompletableFuture/CountDownLatch、Python用asyncio.Future、Go用带缓冲的channel、C#用TaskCompletionSource），把请求ID和等待原语的映射存在带TTL的线程安全缓存里
• 调用等待原语的超时阻塞方法挂起当前请求，线程进入WAITING状态不会占用CPU
• 当/foo_callback接口收到回调请求，先从参数里取出关联的请求ID，从缓存中查到对应的等待原语，把回调结果注入原语，直接唤醒等待的请求线程
• 被唤醒的请求线程拿到回调结果后直接返回给客户端，同时删除缓存中对应的条目

必须给阻塞等待设置合理的超时阈值（比如10s/30s，根据你的业务SLA定），超时后直接返回给客户端「处理超时」类错误，绝对不能无限等待。

技术栈选型参考 #

根据你的部署规模选就行，不需要上过重的中间件：

• 单实例部署场景：直接用语言自带的并发容器+等待原语就能实现，零额外依赖。比如Java用ConcurrentHashMap存ID和CompletableFuture的映射，Go用sync.Map搭配channel，代码量不超过50行，性能最高。
• 多实例部署场景（服务集群部署多个节点）：本地存映射会出现「请求打到A节点，回调打到B节点找不到对应等待上下文」的问题，二选一即可：
  • 用Redis做轻量协调：用请求ID做Key存回调结果，请求侧调用Redis的BLPOP阻塞读命令等待结果，回调侧收到请求后往对应的Key写值，天然支持超时配置，不需要自己实现轮询逻辑
  • 网关层配置一致性哈希规则：把同一个请求ID的所有关联流量（包括初始请求和后续回调）永远路由到同一个服务节点，这样就可以复用单实例的本地内存方案，性能比引入Redis更高。

必做的避坑处理 #

• 绝对不要用普通非线程安全的Map存请求映射，高并发下大概率出问题
• 缓存里的所有请求映射条目必须设置TTL过期时间，防止回调丢包导致内存泄漏
• /foo_callback接口要做幂等校验，避免重复回调触发异常
• 如果是用线程池模型的服务（比如Java Tomcat），要同步调整容器的线程数和接口超时配置，避免大量等待请求耗尽工作线程池

内容的提问来源于stack exchange，提问作者Nil