Question

如果我使用CometD长轮询：

假设一秒钟内有1000条消息要发送给订阅者，CometD是否允许对它们进行自动批处理，以便每个客户端不必为每条消息重新连接？

执行“延迟频道”（如此处所述：http://docs.cometd.org/3/reference/#_java_server_lazy_messages）在超时时发送给客户端的自动批量排队消息？

如果另一方面我不使用懒惰频道，并假设我在频道1,2和3上“批量发布”消息：

cometd.batch(function()
{
    cometd.publish('/channel1', { product: 'foo' });
    cometd.publish('/channel2', { notificationType: 'all' });
    cometd.publish('/channel3', { update: false });
});

（http://docs.cometd.org/3/reference/#_javascript_batch）

订阅所有3个频道的客户是否也批量接收它们？或者它是否单独发送它们，迫使客户端在每条消息之后重新连接（慢）？

Answer 1

CometD为应用程序开发人员提供对批处理功能的完全控制，从而实现最大的灵活性，性能和可扩展性。

使用HTTP long-polling传输时，有两个地方可能会发生批处理。

使用CometD API和显式批处理（如上面的代码段）解决了从客户端到服务器的问题。虽然CometD进行内部批处理以避免耗尽与服务器的连接，但在此级别进行批处理通常可以控制应用程序。

从服务器到客户端有更多变化。

对于广播非延迟频道，没有自动化，通常发生的事情是发送给客户端（不是发布者）的第一条消息将触发消息队列的刷新;在发送此消息时，其他消息将在服务器端为该客户端排队，并在下一个/meta/connect刷新整个队列。对于10条消息，该方案可能类似于： 1-flush-9-flush （排队1，刷新队列，在等待/meta/connect回来时将其他9队列入队列，同花顺另外9）。

对于广播懒惰频道，存在自动化，因此CometD将在rules延迟消息之后发送这些消息之前等待。典型的方案可能是： 10-flush 。

对于服务渠道，一切都恢复了对应用程序的控制。客户端可以通过服务通道（其消息不由CometD自动广播）将批量消息发送到应用程序。服务器上的应用程序可以接收第一条消息并知道其他9消息将会到来，因此它可以等待发送它们直到最后一条消息到达。当最后一个到达时，它可以使用批处理API将响应批处理到客户端，例如：

List<ServerSession> subscribers = ...;
for (ServerSession subscriber : subscribers) {
    subscriber.batch(() -> {
        subscriber.deliver(sender, "/response", response1);
        subscriber.deliver(sender, "/response", response2);
        subscriber.deliver(sender, "/response", response3);
    });
}

当然，回复可能与收到的内容和号码不同。这里的方案几乎可以是应用程序想要的任何东西，但通常将它作为 10-flush ，这是最有效的。

关于批量发送回发布者的邮件的说明。这是一个特殊情况，默认情况下是自动化的：在处理来自该发布者的传入消息时，CometD为该特定发布者启动内部批处理，以便将要传递回发布者的任何消息进行批处理并将在以下处理时刷新处理传入消息的结束。

最重要的是，CometD已经很好地调整，以便在常见情况下提供最大的性能和可伸缩性，但仍然留下应用程序空间来定制行为，以使用应用程序特定的消息模式知识实现最高效率。

我鼓励您查看CometD documentation, tutorials and javadocs。

CometD长轮询 - 它是否能很好地适应高流量？

1 个答案: