Cloud Tasks调用getTask报错 如何轮询获取任务执行结果

你碰到的The task no longer exists, though a task with this name existed recently是Cloud Tasks的正常行为，不是代码bug。Cloud Tasks的设计逻辑是：任务被派发执行后，无论执行成功还是失败，都会立即从队列中删除，服务本身不会留存任务执行状态、也不会存储任务执行的返回结果，所以从设计上就不可能通过轮询getTask()方法拿到任务执行结果。

不需要轮询Cloud Tasks本身的任务状态，加一层自管理的结果存储就能实现需求，步骤如下：

• 创建Cloud Tasks任务时，为每个搜索请求生成全局唯一的请求ID，把这个ID作为任务载荷的一部分，传给处理任务的Worker服务
• Worker消费任务、调用外部搜索API拿到结果后，将结果写入带过期时间的KV存储（推荐用Redis、Cloud Memorystore这类低延迟存储，key设为之前生成的请求ID，过期时间设为10秒即可，避免冗余数据占用空间）
• 后端服务在确认任务成功投递到队列后，立刻把对应的请求ID返回给前端
• 前端拿到请求ID后，以300-500毫秒的间隔轮询自定义的结果查询接口，接口根据请求ID去KV存储里查对应结果，查到就直接返回给前端，超过5秒没查到就返回超时错误
  如果不想做前端轮询，也可以在Worker拿到结果后，通过WebSocket、SSE主动把结果推给对应前端连接，延迟更低，但实现成本比轮询稍高，对你这个1-2秒等待的场景来说轮询完全够用。

你这个搜索场景用户等待时间只有1-2秒，用Cloud Tasks其实有点过重——Cloud Tasks更适合执行时间长、重试逻辑复杂的异步任务（比如发邮件、跑批处理），用在秒级返回的用户侧请求场景，反而要额外处理结果同步问题，链路变长还容易出问题。可以考虑更轻量的实现思路：

• 单实例部署场景：直接用内存队列做限流即可，Node.js生态下可以直接用p-queue库，初始化队列时配置interval: 1000、intervalCap: 外部API允许的每秒请求上限，所有搜索请求直接入队排队执行，请求全程在同一个HTTP连接里等待结果，不需要额外做结果存储、跨服务通信，代码量比接入Cloud Tasks少80%以上。
• 多实例部署场景：用Redis实现分布式令牌桶/分布式队列即可，令牌生成速率严格匹配外部API的QPS上限，所有实例的请求先去Redis抢令牌，抢到就直接调用API，没抢到就短暂等待重试，整个请求链路不需要异步派发，也不用维护单独的Worker集群，运维成本更低。
  不管用哪种方案，记得给外部API调用加上异常重试逻辑，碰到限流类错误码时做短时间的指数退避重试，减少偶发报错对用户的影响。

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