学习jms一些心得

最新推荐文章于 2025-08-12 12:09:07 发布

weixin_34194087

最新推荐文章于 2025-08-12 12:09:07 发布

阅读量65

点赞数

CC 4.0 BY-SA版权

文章标签： netty java python

原文链接：https://my.oschina.net/u/937710/blog/125839

本文详细介绍了使用JMS消息中间件实现多对一消息推送的方案，包括建表设计、用户上线通知处理、消息缓存与推送逻辑等关键步骤。文章深入探讨了如何通过消息队列和发布/订阅模式高效地将信息推送给多个目标用户，同时确保消息的完整性和时效性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

2019独角兽企业重金招聘Python工程师标准>>>

包括两种模式：

点对点

pub/sub

点对点的实现：Queue，增加一些错误异常处理及恢复机制。

pub/sub:首先，是一对多。如果只是用一个Queue存储，用完就丢掉，肯定是不好的，第一个用户收到了，后面n-1个用户就得丢失信息了。

如果我实现jms，我会这么实现（下面会用到QQ中的一些术语）：

建表：

queue表：相当于QQ群了。有多少个QQ群，在这个表中就有多少条记录。

id , create_time,creator,name,type(大群，小群),desc

user表：关联user和queue之间的关系，user的详细信息无需在这儿指出，可以新建详细信息表。

content表：jms收到的所有的message，包括消息来自哪个群，由谁发出。

在表之上用缓存建立一些映射关系，尤其是用户与群之间用一个map建立关联。

当用户上线的时候，发送通知给jms系统。jms系统收到通知，找user对应的群信息，根据用户发送的最后一条群消息的id，来判断是否需要向用户把剩下的所有消息进行推送。

当然，这只是一种设计方案，甚至可以是动态创建表，使得每个群都能有一个单独的queue表。

当然，上面的实现方式和smartfoxserver的思想有些许相似。

对于connection的实现，可以用长连接，因为在上线后，基本会一直在那儿等着。如果用短连接的话，则需要不断地去找topic，看自己是属于哪个群。

<bean id="transportConfiguration" class="org.hornetq.api.core.TransportConfiguration">
		<constructor-arg
			value="org.hornetq.core.remoting.impl.netty.NettyConnectorFactory" />
		<constructor-arg>
			<map key-type="java.lang.String" value-type="java.lang.Object">
				<entry key="host" value="${jms.address}"></entry>
				<entry key="port" value="${jms.port}"></entry>
			</map>
		</constructor-arg>
	</bean>

看上面的配置文件，我们知道jms的实现把流处理（长连接处理）交给了netty管理。

转载于:https://my.oschina.net/u/937710/blog/125839