Activemq 配置说明

threejin

贡献于2012-05-14

字数:4966 关键词: ActiveMQ 消息中间件

Activemq配置说明 1 概述以及ACTIVEMQ集群方案选择 1 1.1 CONSUMERS的集群 1 1.2 BROKERS的集群 1 1.3 集群方案的选择 2 2 服务端配置ACTIVEMQ配置 2 2.1 服务端配置ACTIVEMQ.XML 2 2.2 客户端配置BACKEND-MQ-CONSUMER.XML 2 3 测试 3 3.1 采用单机方式,同步方式 3 3.2 采用单机方式,异步方式 4 4 待解决的问题 5 1 概述以及activemq集群方案选择 1.1 consumers的集群 ActiveMQ支持订阅同一个queue的consumers上的集群。如果一个consumer失效,那么所有未被确认(unacknowledged)的消息都会被发送到这个queue上其它的consumers。如果某个consumer的处理速度比其它consumers更快,那么这个consumer就会消费更多的消息。 1.2 brokers的集群 在一个网络内运行多个brokers或者stand alone brokers时存在一个问题,这就是消息在物理上只被一个broker持有,因此当某个broker失效,那么你只能等待直到它重启后,这个broker上的消息才能够被继续发送(如果没有设置持久化,那么在这种情况下,消息将会丢失)。 1.3 集群方案的选择 经筛选我们采用主--从方式,Master Slave 背后的想法是,消息被复制到slave broker,因此即使master broker遇到了像硬件故障之类的错误,你也可以立即切换到slave broker而不丢失任何消息。Master Slave是目前ActiveMQ推荐的高可靠性和容错的解决方案。并且我们采用文件系统做持久化,即:Shared File System Master Slave。可以运行多个broker,这些broker共享数据目录。当第一个broker得到文件上的排他锁之后,其它的broker便会在循环中等待获得这把锁。 客户端使用failover transport来连接到可用的broker。 当master broker失效的时候会释放这把锁,这时候其中一个slave broker会得到这把锁从而成为master broker。 方案选择:服务端(Shared File System Master Slave)+ 客户端(failover transport) 2 服务端配置activemq配置 2.1 服务端配置activemq.xml 路径:(%activemq_home%/conf/activemq.xml) Master端不需要特殊配置,主要是Slave端的配置如下: 注意: 1. 2. 3. 4. 5. 6. 7. 2.2 客户端配置backend-mq-consumer.xml ActiveMQ目前支持的transport有:VM、TCP、UDP、Peer、Multicast、HTTP、HTTPS、Failover等。 这里我们使用Failover Transport,它是一种重新连接的机制,它工作于其它transport的上层,用于建立可靠的传输。它的配置语法允许制定意多个复合的URI.会自动选择其中的一个URI来尝试建立连接,如果没有成功,那么会选择一个其它的URI来建立一个新的连接,如下代码片段所示: 注意: 1. 2. 3. 4. 5. 这些参数的具体使用根据实际需要而定 3 测试 3.1 采用单机方式,同步方式 设置: , 场景描述: 三个线程,每个线程生产1000万个消息,并开启一个消息者进行消费 结果: 可以存大概280w条数据,存储大概是1g硬盘+20mb内存;用时大既是十几个小时(起初平均每秒100条数据甚至更快,后来速度放慢所以致使整个处理过程耗时较长)。 分析: 从日志及配置分析可知,吞吐量及处理速度是由如下配置所致: 注意: SystemUsage配置设置了一些系统内存和硬盘容量,当系统消耗超过这些容量设置时,amq会放慢生产,当无空间可用,且继续生产是等待时间过长后最终导致了一个异常:Software caused connection abort: recv failed,产生原因是在服务端/客户端单方面关闭连接的情况下,另一方依然以为tcp连接仍然建立,试图读取对方的响应数据。 3.2 采用单机方式,异步方式 设置: , 场景描述: 三个线程,每个线程生产1000个消息,并开启一个消费者进行消费,模拟每次消费耗费60秒时间,中途拔除网线模拟断网较长时间后重新连接上,导致数据丢失,且生产者、消费者报出连接超时异常,此时再打开一个生产者生产1000条数据,只有部分数据(300多条)被消费,造成消费不被消费。 3. 采用集群方式,用文件持久化存储,客户端用failover传输,可以解决broker服务端宕机问题,实现错误转移,并且宕机没消费完的消息,可以继续被消息。 综上所述结论如下: 消息生产者使用持久(persistent)传递模式发送消息的时候,Producer.send() 方法会被阻塞,直到 broker 发送一个确认消息给生产者,这个确认消息暗示生产者 broker 已经成功地将它发送的消息路由到目标目的并把消息保存到二级存储中。这个过程通常称为同步发送。但有一个例外,当发送方法在一个事物上下文中时,被阻塞的是 commit 方法而不是 send 方法。commit 方法成功返回意味着所有的持久消息都以被写到二级存储中。 同步发送持久消息能够提供更好的可靠性,但这潜在地影响了程序的相应速度,因为在接受到 broker 的确认消息之前应用程序或线程会被阻塞。如果应用程序能够容忍一些消息的丢失,那么可以使用异步发送。异步发送不会在受到 broker 的确认之前一直阻塞 Producer.send 方法。如果想启动异步传送可以把 connector uri 的 jms.useAsyncSend 选项设为 true,如下所示:tcp://localhost:61616?jms.useAsyncSend=true。 从 ActiveMQ 5 开始可以控制异步发送流。也就是说,在受到 broker 的确认应答之前,生产者能够传送消息给 broker 的最大信息量。即使是异步发送消息,生产者也是在收到 broker 的确认应答后才把下一条消息传送给 broker。当使用异步传送的时候,可以设置 jms.producerWindowSize(单位为字节)属性,当生产者中等待发送的信息量到达设置的值时,即使没有收到 broker 的应答消息,生产者同样会把这些消息发给 broker。如下面的示例设置:tcp://localhost:61616?jms.useAsyncSend=true&jms.producerWindowSize=1024000 而采用集群方式并使用文件系统做持久化存储可以解决上述问题,致于使用同步还是异步方式发送数据需根据实际需要而定,为确保消息不丢失选择同步,但影响效率(一旦阻塞需重启服务维护麻烦代价较高),若允许部分数据丢失情况,建议使用非阻塞的异步方式(推荐使用)。另外需要注意的是,Queue中的消息是按照顺序被分发到consumers的。然而,当你有多个consumers同时从相同的queue中提取消息时,你将失去这个保证。因为这些消息是被多个线程并发的处理,故如果应用对于消息的顺序要求较严谨,需保证一个queue固定一个消费者来保证顺序。 4 待解决的问题 1. 单机系统时,由于网络中断有时可导致阻塞,或是消息丢失,需重启activemq服务端后,消费者可以继续消费(使用文件系统持久化存储)。 2. 对于activemq的底层原理及实现机制,响应方式,同步异步以及activemq服务端activemq.xml的详细配置和性能调优有待进一步完善和优化。 3. 由于网络问题,以及模拟生产环境而非正式生产环境造成的根实际偏差,测试数据及结果仅供参考,有待进一步验证。 4. 无论是选用主从方式集群,还是选择持久化方式(文件系统或DB)的优劣方面上都还需在实际应用测试中得到论证从而最终确定最佳方案。 5. Activemq是开源项目,其本身还存在一些bug甚至是致命的,所以使用中应加以重视,待activemq出现一个更加完善的稳定版本,可考虑更换中间件。 6. 其它测试以及本文中未提及的隐患问题。

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 3 金币 [ 分享文档获得金币 ]
1 人已下载

下载文档

相关文档