订阅者与订购密钥的亲和力，但没有“按顺序”交付
据我了解， orderingKey 指定在向特定主题发布消息时将消息发布到的分区。我还了解到，为给定的排序键提供了关联性，以决定哪个订阅者实例应该接收具有特定排序键的消息。现在我的问题是：
订阅是否需要启用排序，即确保按顺序传递消息，以便与排序键具有亲和力。我的用例实际上并不需要串行传递特定排序键的消息，但它确实需要关联性（具有相同排序键的所有消息都传递到同一个订阅者实例）。换句话说，我需要一种方法来确保给定分区仅由单个订阅者处理，但我不关心它们在该分区内各自的顺序。
As far as I have understood, the orderingKey specifies the partition to which a message is published when publishing a message to a particular topic. I have also come to understand that affinity is provided for a given ordering key as to which subscriber instance should receive messages with a specific ordering key. Now my question:
Does a subscription need to enable ordering, i.e. ensure delivery of messages in-order for there to be affinity for an ordering key. My use case does not really require serial delivery of messages of a particular ordering key, but it does require affinity (that all messages with the same ordering key is delivered to the same subscriber instance). In other words, I need a way to ensure that a given partition is only processed by a single subscriber, but I do not care about their respective order within that partition.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
即使启用了有序交付，Cloud Pub/Sub 中的亲和力也是尽力而为的。只要当前没有针对该密钥的消息，密钥就可以在不同订阅者之间转移。这种尽力而为的关联仅适用于启用排序的订阅。对于无序订阅，排序键本质上被忽略，消息被任意传递给订阅者。目前，实现关联性的最佳方法是使用属性和过滤，其中订阅会进行检查相同的属性并寻找不同的值。
Even with ordered delivery enabled, the affinity in Cloud Pub/Sub is best-effort. It is possible for keys to shift among different subscribers as long as there are no messages for that key currently outstanding. This best-effort affinity only exists for subscriptions with ordering enabled. For unordered subscriptions, the ordering key is essentially ignored and messages are delivered to subscribers arbitrarily. Currently, the best way to achieve affinity is to use attributes and filtering, where subscriptions examine the same attribute and look for different values.