学习jms一些心得

包括两种模式：

点对点

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管理。