google-cloud-platform - Google Cloud Pub/Sub 如何避免时钟偏差

Question

我正在研究从 google cloud pub/sub 订购消息列表的方法。 The documentation说:

Have a way to determine from all messages it has currently received whether or not there are messages it has not yet received that it needs to process first.

...is possible by using Cloud Monitoring to keep track of the pubsub.googleapis.com/subscription/oldest_unacked_message_age metric. A subscriber would temporarily put all messages in some persistent storage and ack the messages. It would periodically check the oldest unacked message age and check against the publish timestamps of the messages in storage. All messages published before the oldest unacked message are guaranteed to have been received, so those messages can be removed from persistent storage and processed in order.

我在本地进行了测试，这种方法似乎运行良好。

然而，我对此有一点提示，而且这不是一件容易由我自己测试的事情。

该解决方案依赖于服务器端分配(由google)publish_time属性。 Google 如何避免时钟偏差问题？

如果我的生产者发布了消息 A，然后立即发布了 B，我如何确定 A.publish_time < B.publish_time是真的？特别是考虑到同一文档页面提到了解决方案架构中的内部负载均衡器。 Google Pub/Sub 是否使用原子钟来同步第一批看到消息的机器上的时间，并用当前时间丰富这些消息？

推荐的解决方案中有一个隐含的假设，即所有服务器上的时钟都是同步的。但文档从未解释这是否属实或如何实现，所以我对这个解决方案感到有点不安。它可以在非常高的负载下工作吗？

注意，我只对彼此之后发布的已确认消息的相对顺序感兴趣。如果同时发布两条消息，我不关心它们之间的顺序。可以是A, B或B, A 。我只想确保如果 B 在 A 发布之后发布，那么我可以在检索时按该顺序对它们进行排序。

上述解决方案只是“尽力而为”还是对此行为有实际保证？

Answer 1

有序消息传递有两个方面:在发布端建立消息顺序和在订阅端建立处理消息的顺序。您引用的文档主要与后者有关，特别是在使用oldest_unacked_message_age 时。使用这种方法时，我们可以知道，如果消息 A 的发布时间戳小于消息 B 的发布时间戳，那么订阅者总是会在处理消息 B 之前先处理消息 A。本质上，一旦订单建立(通过发布)时间戳)，它将是一致的。如果 Cloud Pub/Sub 服务本身可以建立消息的排序，则此方法有效。

发布时间戳在服务器之间不同步，因此如果发布者需要建立订单，则发布者需要提供时间戳(或序列号)作为用于排序的属性在订阅者中(并在发布者之间同步)。订阅者将按用户提供的时间戳而不是发布时间戳对消息进行排序。 oldest_unacked_message_age 将不再准确，因为它与发布时间戳相关。人们可能会更加保守，只考虑早于 oldest_unacked_message_age 的消息排序减去一些增量来解释这一差异。