JMS(或任何消息传递解决方案)是否适用于关注者/关注模型

Question

为了简单起见,我们假设我正在克隆twitter(我不是).因此,每个用户都可以关注其他用户,并被其他用户关注.对于您关注的每个用户,您会收到他发送的所有推文.一切都存储在数据存储中(无论是NoSQL解决方案还是分片关系数据库).

但是,当用户在线时,您是否认为让他们通过JMS接收推文是合适的,而不是轮询数据库并检索新的推文:

• 当用户注册时(或登录时),创建一个以他(或他的id)命名的JMS主题
• 当用户登录时,他订阅了他所关注的每个用户的JMS主题
• 会话范围的对象(每用户)充当JMS消息侦听器
• 所有收到的消息都存储在会话中(内存中)
• UI通过会话范围对象的ajax轮询更新
• 当用户注销或其会话超时时,消息监听器将被销毁

据称这背后的想法是为了提高性能 - 即不是过于频繁地查询数据存储区,而是在内存中缓存直接内容.

整个过程当然应该在集群中运行,并且可以扩展.

但是我不确定:

• 这是否真的值得(在性能和可扩展性增益方面)
• JMS是否不会增加不必要的开销,这等于查询数据存储区(从而使整个复杂化无用)

在某些时候(当事情有效时)我会做一些基准测试,但我想听一些初步的评论.

Answer 1

听起来很合理。您需要确保您选择的 JMS 实现支持潜在的大量主题 - 并非所有主题都能优雅地做到这一点。

我的主要设计问题是，当用户首次登录时，他的会话消息存储将为空，您必须等待它填满。无论如何，您是否都必须访问数据库，或者这不是问题。

另外，您在这里并没有真正利用 JMS 的事件驱动特性。从主题接收到的消息只是转储到会话存储中以供以后检索。

由于它并不是真正的事件驱动，您也许可以考虑使用分布式内存数据存储，例如 EhCache+JGroups 或 JBossCache3（我强烈推荐）。新的推文将被放入这个分布式存储中，读者只需在其中搜索感兴趣的内容即可。这可以提高内存效率，因为每个节点上只存储每条推文的一个副本。您还可以在系统启动时预加载缓存。