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