我的应用程序将按以下方式运行：
我将拥有一堆副本服务器和一个负载均衡器。数据更新将在CometD之外进行管理。编辑：如果有必要，我仍打算通知每个CometD服务器这些更新，以便他们回复客户。
客户端只订阅这些更新（即只读），因此CometD服务器节点不需要了解彼此的行为。
我是否正确地认为我可以在负载均衡器上为每个客户端连接提供服务器端“客户端”实例，其中每个实例在与其各自客户端相同的通道上进行侦听并将任何消息转发回它？如果是这样，这种方法是否有任何缺点，而不是使用Oort？
阅读关于奥尔特的文档，似乎节点“相互了解”，我不需要。在我的情况下，对我来说完全避免使用Oort会更好吗？我担心的是，如果我最终添加了许多节点，那么他们与“彼此”进行通信的事实可能意味着不必要的处理？
答案 0 :(得分：0)
问题描述指出数据更新是在CometD之外进行管理的，但没有详细说明如何通知CometD服务器这些数据更新。
两种常见的解决方案是A）通知每个CometD服务器或B）使用Oort。
在解决方案A）中，您有一个触发数据更新的事件，而某些外部应用程序在数据库上执行数据更新。此时，外部应用程序必须通知CometD服务器存在数据更新。如果外部应用程序在JVM上运行，它可以使用CometD Java客户端向每个CometD服务器发送消息，通知它们数据更新;反过来，CometD服务器将通知远程客户端。
在解决方案B）中，外部应用程序必须只通知一个CometD服务器有数据更新; Oort集群将完成剩下的工作，在整个集群中广播该消息，然后再到远程客户端。
解决方案A）不需要Oort群集，但要求外部应用程序准确知道所有节点，并向每个节点发送消息。
解决方案B）使用Oort，因此外部应用程序只需知道一个Oort节点。
Oort需要一些额外的处理，因为节点是互连的，但根据情况，此处理可以忽略不计，或者“手动”（如解决方案A）通知每个CometD服务器的复杂性可能大于运行Oort
我不明白你在负载均衡器上有“服务器端客户端实例”是什么意思。通常，负载均衡器不运行JVM，因此无法在它们上运行CometD客户端，因此这句话听起来不对。
除CometD documentation外，您还可以查看these slides。