Google Cloud Pub/Sub 如何避免时钟偏差
How is Google Cloud Pub/Sub avoiding clock skew
我正在研究从 google 云 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 发布之后发布，那么我可以在检索时按该顺序对它们进行排序。
上述解决方案只是“尽力而为”还是对这种行为有实际保证？
Google Cloud Pub-sub 不保证事件在生成时接收到消费者的顺序。这背后的原因是 Google Cloud Pub-sub 也在节点集群上 运行。有可能事件 B 可以在事件 A 之前到达消费者。为了确保顺序，您必须对生产者和消费者进行更改以确定事件的顺序。 Here 是来自文档的部分。
有序消息传递有两个方面：在发布端建立消息顺序，在订阅端建立处理消息的顺序。您所参考的文档主要关注后者，尤其是在使用 oldest_unacked_message_age 时。使用这种方法时，可以知道如果消息A的发布时间戳小于消息B的发布时间戳，那么订阅者总是先处理消息A再处理消息B。本质上，一旦顺序建立（通过发布时间戳），它将是一致的。如果云 Pub/Sub 服务本身可以建立消息的顺序，则此方法有效。
发布时间戳在服务器之间不同步，因此如果发布者有必要建立订单，则发布者有必要提供时间戳（或序列号）作为使用的属性用于在订阅者中订购（并在发布者之间同步）。订阅者将按此用户提供的时间戳而不是发布时间戳对消息进行排序。 oldest_unacked_message_age 将不再准确，因为它与发布时间戳相关联。一种可能更保守，只考虑订购早于 oldest_unacked_message_age 的消息减去一些增量来解释这种差异。
我正在研究从 google 云 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_agemetric. 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 发布之后发布，那么我可以在检索时按该顺序对它们进行排序。
上述解决方案只是“尽力而为”还是对这种行为有实际保证？
Google Cloud Pub-sub 不保证事件在生成时接收到消费者的顺序。这背后的原因是 Google Cloud Pub-sub 也在节点集群上 运行。有可能事件 B 可以在事件 A 之前到达消费者。为了确保顺序，您必须对生产者和消费者进行更改以确定事件的顺序。 Here 是来自文档的部分。
有序消息传递有两个方面：在发布端建立消息顺序，在订阅端建立处理消息的顺序。您所参考的文档主要关注后者，尤其是在使用 oldest_unacked_message_age 时。使用这种方法时，可以知道如果消息A的发布时间戳小于消息B的发布时间戳，那么订阅者总是先处理消息A再处理消息B。本质上，一旦顺序建立（通过发布时间戳），它将是一致的。如果云 Pub/Sub 服务本身可以建立消息的顺序，则此方法有效。
发布时间戳在服务器之间不同步，因此如果发布者有必要建立订单，则发布者有必要提供时间戳（或序列号）作为使用的属性用于在订阅者中订购（并在发布者之间同步）。订阅者将按此用户提供的时间戳而不是发布时间戳对消息进行排序。 oldest_unacked_message_age 将不再准确，因为它与发布时间戳相关联。一种可能更保守，只考虑订购早于 oldest_unacked_message_age 的消息减去一些增量来解释这种差异。