作者在http://www.cometdaily.com/2008/05/15/the-many-shades-of-bayeuxcometd-2/index.html的文章中这样描述：
通常使用 PubSub，开发人员需要为每个用户创建一个频道，以便将私人消息传递给客户端。例如，如果交易系统想要通知用户完成的交易，很可能会创建一个类似 /trades/a_user_id 的频道，每个用户都将订阅他们自己的频道。此方法有效，但不是解决此问题的最节省资源的方法，并且需要安全代码来防止未经授权的客户端订阅其他用户频道。
为特定用户实现消息时，服务和广播渠道之间的权衡是什么？我了解权衡的安全方面，但是资源开销呢？我不明白为什么广播频道使用的资源比自定义路由服务使用的资源多。如果你能解释为什么一个在用例上比另一个更好，而不是笼统地声明是否明智，那可能有助于我做出决定。
【问题讨论】：
标签： service broadcast channel cometd bayeux
这篇文章很老了，它指的是 CometD 1，而我们现在在 CometD 3。 您可能想查看CometD website 上的更新并阅读CometD 3 documentation。
广播与服务频道背后的概念仍然适用于 CometD 3。
服务器为每个创建的频道分配数据结构，无论是广播还是服务频道。
在那篇文章的示例中，比较了创建 N 个广播频道（每个 user_id 一个）与仅创建一个服务频道。前一种解决方案显然在服务器上使用了比后者更多的资源，并且容易被偷窥（客户端可以猜到user_id 并订阅该频道，从而接收发往其他用户的消息）。
对于这种特殊情况，应用程序需要做的就是将消息传递给特定的客户端。对于这个用例，最好使用服务通道，因为它使用的资源更少（所有用户都可以使用相同的服务器端通道，而不会有用户收到非发给他/她的消息的风险），而且它是更安全。
【讨论】：
user_id 使用一个服务渠道，但这不是必需的。话虽如此，CometD已经过测试，可以扩展到数万个频道，没有问题——但你还是要注意，如果没有必要，不要浪费资源。 CometD API 允许您高效地将消息发送到单个客户端，因此编写此类应用程序非常容易。