【发布时间】：2017-01-24 06:41:02
【问题描述】：
Google PubSub 是否适合小容量（10 条消息/秒）但任务关键型消息传递，保证在任何固定时间段内及时交付每条消息？
或者，它是否更适合高吞吐量，其中个别消息可能偶尔丢失或无限期延迟？
编辑：稍微改述一下这个问题：PubSub 中的任何特定消息，无论产生的消息量如何，都可以无限期延迟，这是真的吗？
【问题讨论】：
【发布时间】：2017-01-24 06:41:02
【问题描述】：
Google Cloud Pub/Sub 保证所有消息的传递，无论是低吞吐量还是高吞吐量，因此不必担心消息丢失。
从发布者到订阅者的消息传递延迟取决于许多不同的因素。特别是，订阅者能够处理消息和请求更多消息的速率至关重要。对于拉取订阅者，这意味着总是有几个未完成的拉取请求到服务器。对于推送订阅者，他们应该尽快返回成功的 HTTP 响应代码。您可以阅读有关difference between push and pull subscribers 的更多信息。
Google Cloud Pub/Sub 会尽量减少延迟时间，但无法保证。根据经验，Cloud Pub/Sub 在第 99 个百分位处始终在不超过几秒钟的时间内交付消息。请注意，如果您的发布者或订阅者未在 Google Cloud Platform 上运行，那么您的服务器与 Google 服务器之间的网络延迟也可能是一个因素。
【讨论】：
-
谢谢！但是首先你说“保证所有消息的传递”，然后你说“没有保证”。对我来说，这意味着一条单独的消息可能会以任何延迟到达。
-
无法保证延迟，但 Cloud Pub/Sub 保证不会丢失消息。换句话说，由服务引起的延迟肯定不会超过 7 天，即消息的过期时间。最终，Cloud Pub/Sub 可能会提供延迟保证。但是，端到端的保证很难量化，因为它们很大程度上取决于客户的行为。
-
不保证延迟同样意味着从业务角度来看消息可能会丢失。不管怎样，谢谢。重新量化，如果谷歌（或其他任何人）可以分享一些最常见场景的延迟直方图，例如高/低流量、峰值流量等，将会很有帮助。第 99 秒的几秒相当模糊。跨度>
-
由于这是一个常见的陷阱，我认为值得一提的是 Pub/Sub 提供“至少一次交付”，这意味着订阅者需要处理重复/保证幂等性。
-
只有一次交付目前处于公共预览阶段：cloud.google.com/pubsub/docs/exactly-once-delivery