JBoss Seam - 应用程序中的海量消息传递
我目前正在摆弄一个应用程序，该应用程序的设置与以下聊天类比相匹配：
- 聊天是保存在内存中并包含聊天列表的对象 聊天消息
- 在多个浏览器窗口中呈现，并且更新 使用 a4j:push 拉入
编程设置如下所示：聊天对象及其消息的实例在不同会话中的 PAGE 范围接缝组件之间共享。现在，当任何会话发布新消息时，即修改聊天对象时，所有Seam组件都应该收到新消息的通知，以便新状态可以转发到所有客户端上的UI。
我可以想到三种方法来实现这一点：
- Seam 的事件以聊天 ID 作为参数，然后每个组件检查 ID，然后更新或忽略消息
- JMS 队列或一个 JMS 主题，其中每个组件使用过滤器监听它的消息聊天
- 共享聊天对象中的纯Java侦听器机制，即每个seam组件向其注册，并且通知是纯且直接的java
为了便于论证，假设聊天的数量很大（数万）并且聊天用户的数量很小（假设是 2-10）。
每个规模的表现如何？您对于如何使用 Seam 实现此功能并表现良好还有其他建议吗？
在我看来，(1) 将是集成且干净的，但最终您会通知数以万计的组件，而只有少数组件真正需要它。所以它可能无法扩展。
(2) 将被集成，并且仅依赖于 JMS 提供者（可以交换）的性能，并且无需修改也可以在集群环境中工作。我不确定这里 JMS 的性能，即每秒数百条消息和具有不同过滤器的数千个侦听器是否多？
(3) 会很快，因为只有所需的组件才会被通知，并且通知是纯粹的、直接的 java.lang.但是，由于完成了跨会话/组件/线程的操作，可能会出现并发/访问问题。
对于 (1) 和 (3)，如果在某些时候需要，则必须手动添加支持集群的解决方案。
I'´m currently twiddling with an application that has a setup matching the following chat analogy:
- a chat is an object that is held in memory and contains a list of chat
messages - a chat is rendered in several browser windows and updates are
pulled in with a4j:push
The programmatic setup looks like this: an instance of a chat object with it's messages is shared between PAGE scoped seam component in different sessions. Now, when any session posts a new message, i.e. modifies the chat object, all seam components should be notified of the new message so that the new state can be relayed to the UI on all clients.
I can think of three ways to achieve this:
- Seam's events with the chat ID as a parameter and then each component checks the ID and either updates or ignores the message
- JMS Queues or one JMS topic where each component listenes on with a filter for just it's chat
- a pure Java listener mechanism in the shared chat object, i.e. each seam component registers to it and the notification is pure and direct java
For the sake of argument assume the number of chat's is large (tens of thousands) and the number of chat users is small (let's say 2-10).
How does each scale performance wise? Do you have any other suggestions how make this with Seam and performing well?
As I see it, (1) would be integrated and clean, but eventually you'd notify tens of thousand of components where only a few actually need it. So it probably won't scale.
(2) would be integrated and only depend on the performance of the JMS provider (which can be exchanged) and would also work in a clustered environment without modifications. I'm not sure about the performance of JMS here, i.e. are a few hundred messages per second and thousand of listeners with different filters much or not?
(3) would be fast, because only the required components would be notified and the notification is pure and direct java. However, concurrency / access problems may arise because something cross session / component / thread is done.
For (1) and (3) a solution that supports clustering would have to be added manually if required at some point.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我推荐2）。我还建议将 JMS 排除在外 - 尽管它可以让您切换消息传递提供程序，但它也会阻止您使用消息传递系统的更高级功能。如果您使用的是 Oracle 数据库 AQ会做出明智的选择（顺便说一句，它支持 JMS）。否则，我建议使用 AMQP，它应该可以通过 JBoss Messaging 或第三方解决方案（如 RabbitMQ。
由于您显然存在消息传递问题，因此您应该选择使用消息传递解决方案。
I'd recommend 2). I would also recommend cutting JMS out of the equation - even though it will enable you to switch messaging providers it will also make prevent you from using the more advanced features of your messaging system. If you are using an Oracle database AQ would make a sensible choice (it supports JMS btw.). Otherwise I'd recommend using AMQP which should be available through JBoss Messaging or a third party solution like RabbitMQ.
Since you clearly have a messaging problem you should opt for using a messaging solution.