在什么情况下 Google Cloud Pub/Sub 会关闭订阅？
我正在使用 Google Cloud Pub/Sub：Node.js 客户端 2.19.0。
有时会发生某些订阅上的消息根本没有被确认的情况。我怀疑订阅有时会出现问题。 我有一个 subscription.on('error', ... 监听器。但是，当问题发生时，这个监听器显然不会被触发。
难道订阅就关闭了，没有抛出错误吗？
我在官方文档中找不到任何背景信息，但它们需要以下内容关于事件处理程序：
// Register a close handler in case the subscriber closes unexpectedly
subscription.on('close', () => {});
这引发了问题：在哪些情况下订阅会意外关闭？
添加监听器以重新打开是否有意义
subscription.on('close', () => {
subscription.open()
});
？
如果是这样：区分意外关闭（我想通过重新打开来做出反应）的首选方法是什么？我自己的程序代码故意关闭了订阅（在这种情况下我不想自动重新打开订阅）？
I am using Google Cloud Pub/Sub: Node.js Client 2.19.0.
It happens from time to time that messages on some subscriptions simply do not get acked. My suspicion is that something with the subscription goes wrong sometimes.
I have a subscription.on('error', ... listener. However, this listener is obviously not triggered when the problem occurs.
Could it be that the subscription is closed without an error being thrown?
I could not find any background information in the official docs but they entail the following about event handlers:
// Register a close handler in case the subscriber closes unexpectedly
subscription.on('close', () => {});
That raises the question: In which cases is subscription closed unexpectedly?
Does it make sense to add a listener for re-opening like
subscription.on('close', () => {
subscription.open()
});
?
If so: What would be the preferred way to distinguish between unexpected closing (to which I want to react by re-opening) and my own program-code having closed a subscription on purpose (in which case I do not want to re-open the subscription automatically)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
订阅者不应在没有抛出错误的情况下关闭。订阅者被关闭的原因有多种，包括：
一个问题是，消息未得到确认是什么意思？是否是在您相信已对消息调用
ack之后，您再次收到消息？是不是您在云监控中看到的未确认消息数量没有减少？如果您的消息没有得到确认，可能有许多不同的原因。可能是您的消息处理失败并且没有确认消息。这不会导致整个订阅者出错，但只会导致未处理的消息最终出现
nack。在回调一开始就记录您收到的每条消息并记录每个确认会很有帮助，以确保您确认了每条消息。您还可能会在文档中遇到有关批量消息的 ack 的说明：
如果缺少确认的情况相对较少，那么您可能会遇到 Pub/Sub 的至少一次传送保证，即使您确实发送了确认的消息仍然可以重新传送，即使没有上述关于批处理的警告。
A subscriber should not be closed without an error being thrown. There are several reasons why a subscriber may be closed including:
One question would be, what do you mean by messages are not getting acked? Is it that you are getting the messages again after you believe you have called
ackon them? Is it that the number of unacked messages you see in Cloud Monitoring is not decreasing?If your messages are not getting acked, there could be many different causes. It could be that your message processing failed and didn't ack the message. This would not cause the entire subscriber to error out, but would only result in an eventual
nackfor the message that wasn't processed. It can be helpful to log every message you receive at the very beginning of your callback and log every ack to ensure that you are acking every message.You could also be running into the note about acks for batched messages in the documentation:
If the lack of acking is relatively infrequent, you could just be running up against Pub/Sub's at-least-once delivery guarantees, where even messages for which you do send an ack could still be redelivered, even without the aforementioned caveat about batching.