基于ActiveMQ的Topic的数据同步——消费者持久化

一、前言

在前一篇《基于ActiveMQ的Topic的数据同步——初步实现》中，大概介绍了项目中使用ActiveMQ的场景，并贴了相关的代码，因本人也是初学者，对ActiveMQ没有深入的研究，只是在项目当中使用了，写些文章，分享一下我的经历。

在《基于ActiveMQ的Topic的数据同步——初步实现》中贴的代码，因为木有对消息进行持久化，有时候会造成消息的丢失，在我项目使用过程中，如果Web应用部署到我本机子上，而ActiveMQ的Server是远程的，则同时发送两条消息时，消息不会造成丢失，而部署了Server上面之后，经测试人员反馈，发现同时发送两条数据时候，消费者只能接收到一条消息，本来也查了一下原因，实在是搞不明白，后经与技术群讨论，才发现是消息没有持久化造成的，后经修改，重新部署之后，暂时还木有发现消息丢失的情况，现将配置代码贴了，分享一下。

 

二、配置

1、消息发送方

在消息发送时，需要为消息发送方配置一个clientIDPrefix的一个属性，该属性来表示那个消费者可以获得此消息，配置文件如下：

clientIDPrefix：指定了consumer的clientID的前缀，符合此前缀规则的consumer将成为该TOPIC的持久订阅者。

2、消息接收者

Durable Subscription：

对于通常的消息订阅来说， JMS Provider会对这类消息订阅者“一视同仁”，你来了，我就给你消息，你走了，我就不管你了。 当消息到达指定Topic之后，JMS Provider只会为已经连接并且订阅了该指定Topic的消息订阅者发送消息， 如果消息到达之后你恰好不在，那不好意思，你将接收不到这一消息。这就好像现在的商场促销活动，礼品(消息)有限，虽然你(相当于消息订阅者)也想获得相应的礼品， 但当发送礼品的时候你不在礼品派发现场的话，你将失去这一获得礼品(消息)的机会，因为商场可不会管你是何方神圣，对于JMS Provider来说， 也是同样道理，只要我(JMS Provider)派发消息的时候你不在，你收不到消息是你自己找的，跟我没有关系。 也就是说，JMS Provider不会“耗费脑筋”去记下谁还没有来接收消息，就跟商场不会纪录到底谁的礼品还没有来领取一样， 因为对于这种情况来说，耗费资源去这些不确定的client， 完全就是non-sense的，不是嘛? JMS Provider或者说商场，根本就不会知道谁会来领取消息或者礼品。

当我们转到Durable Subscription的时候，情况就完全不同了。如果消息订阅者通过Durable Subscription的方式来订阅消息， 那么JMS Provider将会费点儿脑筋来记下这个Durable Subscription的消息订阅者是谁，即使当消息到达之后，该Durable Subscription消息订阅者不在， JMS Provider也会保证， 该Durable Subscription消息订阅者重新回来之后，之前到达而该Durable Subscription消息订阅者还没有处理的消息，将被一个不少的发送给它。

clientId：是在连接时必须提供的，做为subscriptionDurable为ture，必须提供该属性，这个clientId会与JMS Provider的clientPrefixID匹配，才能接到相应的消息

单凭Client Id还不足以唯一标志某一个Durable Subscription，就跟我凭一个身份证，可以预定多个房间一样。 同一个连接里，你可以创建多个MessageConsumer去订阅不同Topic的消息，如果下回回来，你只想继续接受某一个Topic消息的话，JMS Provider如何知道是哪一个？ 所以，为了区分同一个Connection中不同的Durable Subscription，我们还需要进一步的标志物，这就是Subscriber Name！

 

这就是关于subscriptionDurable、clientId、durableSbscriptionName的解释，具体可参阅http://shshy39.iteye.com/blog/487008

 

三、小结

ActiveMQ只是在项目中临时使用，原来项目使用Oracle Service Bus来实现的，时间原因临时采用了JMS，这只是本人在项目中使用过程中所能分享的，当然没有对JMS深入的研究，待以后有时间再研究再分享出来，若有问题，可讨论，一起学习、一起分享。