为了简单起见,我们假设我正在克隆twitter(我不是).因此,每个用户都可以关注其他用户,并被其他用户关注.对于您关注的每个用户,您会收到他发送的所有推文.一切都存储在数据存储中(无论是Nosql解决方案还是分片关系数据库).
但是,当用户在线时,您是否认为让他们通过JMS接收推文是合适的,而不是轮询数据库并检索新的推文：
>当用户注册(或登录时),创建一个以他(或他的id)命名的JMS主题
>当用户登录时,他订阅了他所关注的每个用户的JMS主题
>会话范围的对象(每用户)充当JMS消息侦听器
>所有收到的消息都存储在会话中(内存中)
>通过会话范围对象的ajax轮询更新UI
>当用户注销或其会话超时时,消息侦听器将被销毁
据称这背后的想法是为了提高性能 – 即不是过于频繁地查询数据存储区,而是将直接内容缓存在内存中.
整个过程当然应该在集群中运行,并且可以扩展.
但是我不确定：
>这是否真的值得(在性能和可扩展性增益方面)
> JMS是否不会增加不必要的开销,这等于查询数据存储区(因此使整个复杂化无用)
在某些时候(当事情有效时)我会做一些基准测试,但我想听一些初步的评论.
最佳答案
听起来很合理.您需要确保您选择的JMS实现支持可能非常多的主题 – 并非所有主题都可以优雅地完成.
原文链接：https://www.f2er.com/java/437711.html我的主要设计问题是,当用户首次登录时,他的会话消息存储将为空,您必须等待它填满.那么你是不是必须打到数据库,或者这不是问题.
此外,您并没有真正利用JMS的事件驱动特性.从主题接收的消息将被转储到会话存储中以供以后检索.
由于它不是真正的事件驱动,您可以考虑使用分布式内存数据存储,例如EhCache JGroups或JBossCache3(我强烈推荐).新的推文将被放入这个分布式商店,读者只需要搜索那些寻找感兴趣的项目.这可能更节省内存,因为每个推文上只存储一个每个推文的副本.您还可以在系统启动时预加载缓存.
