分区队列消息传递

事件代理根据消息中携带的键（分区键）将消息分发到分区队列。客户端应用程序在发布时设置此键。事件代理创建分区键的哈希，并使用该哈希值确定特定一组消息发送到哪个分区。所有具有相同键的消息都由同一个分区处理。相关事件及其发布顺序在分区内保持。

下图显示了消息被发布到分区队列。消息的不同颜色代表它们的分区键值。每个分区键值映射到一个分区。然而，一个分区可能映射到多个分区键值。

同样，每个分区映射到一个消费者流程，但一个流程可能映射到多个分区。

多个消费者连接到队列，每个消费者被分配到不同的分区集合。只允许单个消费者被分配到并从任何给定分区消费；然而，单个消费者可能服务于多个分区。由于分区之间不保证消息顺序，这种情况下的消费者可以接收到消息顺序错乱（相对于它们的发布顺序）。在分区内保证消息顺序。

有关支持分区队列的消息API列表，请参见PubSub+消息API中的功能支持。

向分区队列发布

生产应用程序为他们发布的消息设置分区键。如果消息被吸引到分区队列，该键的哈希值决定消息被放置在哪个分区。根据事件代理上的订阅集和其他配置，具有分区键的消息也可能被分发到其他队列。

如果生产应用程序设置了分区键，该键应该具有足够大的范围，以产生均匀分布的哈希值，这些值映射到分区。

如果消息中没有提供分区键，该消息将被随机分配到一个分区。

下图说明了消息序列到达事件代理，然后被分发到一些队列，其中一个是分区队列。在分区队列中，键到分区映射决定哪些消息进入哪些分区。

SMF客户端通过设置发布消息的QUEUE_PARTITION_KEY用户属性来指定分区键。设置此属性的机制因API而异。

JMS客户端直接设置JMSXGroupID属性以提供分区键。

有关如何设置分区键的详细信息和示例，请参见分区键。

AMQP和MQTT客户端可以发布到（但不能从）分区队列。有关详细信息，请参见分区队列功能交互。

从消费应用程序的角度来看，从分区队列接收消息与从任何其他队列接收消息没有什么不同。事件代理和PubSub+消息API透明地处理各个分区的细节。尽管消费者可以通过发布者在消息中提供键来访问，但它不知道消息是从哪个分区传递的，也无法请求来自任何特定分区的消息。

事件代理将一个或多个分区映射到每个消费者流程。下图显示了分区到流程映射。消费应用程序绑定到父队列，提供其所需的属性、消息接收回调等。它有一个单一流程，但来自该队列的一个或多个分区的消息被传递。

添加或移除消费者可能会引起分区再平衡。当以下情况发生时，会触发分区再平衡：

分区再平衡通常还包括分区交接，事件代理在消费者流程之间移动分区。

如果消费者数量多于分区数量，多余的消费者将不会承担任何消息负载。然而，多余的消费者可以扮演备用角色 - 如果活动消费者失败，多余消费者之一的流程随后变得活跃并开始接收消息。

分区可以具有以下状态之一：

当消费客户端绑定到分区队列时，事件代理在绑定响应中将分配的分区集合返回给客户端。类似地，API在后续绑定请求中将映射信息发送回事件代理，尝试重新建立流程在断开连接之前拥有的相同分区映射。

如果被分配到分区的消费者意外断开连接（例如，由于临时连接问题或应用程序崩溃），有几种可能的结果：

在这种情况下，消费者应用程序的API在新的绑定请求中提供映射分区集（它仍然知道），连同队列名称。事件代理将新流程映射到相同的分区，并立即开始向消费者传递消息。在这种情况下，消息流程没有中断，分区到流程映射保持不变。消费者获得与之前断开连接之前相同的分区。

如果消费者重新启动，API无法在绑定请求中提供其先前映射的分区集（由于重新启动而丢失）。随后再平衡计时器到期，事件代理将消费者视为没有分区映射历史的新客户端。事件代理执行分区再平衡，并将任意分区分配给重新连接的消费者。

当再平衡计时器到期时，分区在仍然连接的消费者应用程序之间重新映射。当断开连接的应用程序重新连接时，触发第二次再平衡，现在包括新连接的流程。即使应用程序发送其先前的分区映射（先前的映射被忽略），也会触发第二次再平衡。

消费者应用程序可能由于硬件故障或永久崩溃而保持断开连接。在这种情况下，当再平衡计时器到期时，分区在仍然连接的应用程序之间重新映射。

有关应用程序如何应对分区交接的信息，请参见分区交接。