Google Pub/Sub 如何在 Pull 上设置读取超时

Question

我想在订阅上设置拉取请求的读取超时。 现在唯一的选择是设置returnImmediately=true或者只是等到 pubsub 返回，如果没有消息发布，这似乎是 90 秒。

我正在使用 gcloud-node 模块调用 pubsub。 它使用引擎盖下的请求模块来进行 gcloud api 调用。 我已经更新了gcloud-node/lib/pubsub/subscription.js 的本地副本，将请求超时设置为 30 秒

this.request({
  method: 'POST',
  uri: ':pull',
  timeout: 30000,
  json: {
    returnImmediately: !!options.returnImmediately,
    maxMessages: options.maxResults
  }
}

当我这样做时，我看到的行为是连接将在 30 秒后在客户端超时，但 pubsub 仍然打开请求。 如果我有两个客户端拉取订阅，并且其中一个客户端在 30 秒后超时，那么将向该主题发布一条消息，剩余的侦听客户端将有 50/50 的机会检索该消息。

有没有办法告诉pubsub在一定时间后超时拉连接？

更新：我可能需要稍微澄清一下我的例子。 我有两个客户端同时连接并从同一个订阅中提取。 两者的唯一区别是第一个配置为在 30 秒后超时。 由于两个客户端连接到同一个订阅，pubsub 将在它们两个之间分配消息负载。 如果我在两个客户端连接后 45 秒发布消息，则 pubsub 有 50/50 的机会将消息传递给尚未超时的第二个客户端。 如果我发送 10 条消息而不是一条消息，第二个客户端将收到 10 条消息的子集。 看起来这是因为我的客户正在进行长时间的投票。 如果客户端断开连接，服务器不知道并且将尝试根据已超时的客户端发出的请求的响应发送已发布的消息。 根据我的测试，这是我观察到的行为。 我想要做的是能够在拉取请求中发送一个超时参数，以告诉 subpub 在 30000 毫秒后发回响应，如果在那段时间内没有发布消息。 阅读API 文档，这似乎不是一个选项。

Answer 1

设置请求超时是在 30 秒后超时拉取的正确方法。 被取消的请求的存在可能不是导致另一个 pull 不能立即收到消息的原因。 如果您的第二次拉取（未超时）设法拉取之前发布的其他消息，则它不一定会等待超时后发布的其他消息在完成之前进入。 它既能保证不返回超过maxMessages ，不返回只有一次有确切maxMessages （如果很多可用）。 一旦您的发布完成，稍后的一些拉取将收到该消息，但无法保证确切的发生时间。