JMS(六)--ActiveMQ内置Broker启动方式

本文介绍了三种启动ActiveMQ内嵌Broker的方法:直接代码启动、工厂模式启动及Spring配置启动,并提供了具体实现步骤。

前言

ActiveMQ除了可以作为独立进程单独部署在服务器上之外,也可以很小巧的内嵌在程序中启动,下面我们来简单的介绍内置Broker启动的几种方式。 

首先准备工作还是需要准备好activemq的jar包,请自行配置,不多赘述

<dependency>
	<groupId>org.apache.activemq</groupId>
	<artifactId>activemq-all</artifactId>
	<version>5.15.2</version>
</dependency>

一、代码直接启动

这种方式直接在代码中启动,因为比较简单,就直接上代码了:
package com.tgb.SpringActivemq.test;

import org.apache.activemq.broker.BrokerService;

public class InnerBroker {
	public static void main(String args[]) throws Exception {
		BrokerService broker = new BrokerService();
		// 启用broker的JMX监控功能
		broker.setUseJmx(true);
		// 设置broker名字
		broker.setBrokerName("MyBroker");
		// 是否使用持久化
		broker.setPersistent(false);
		// 添加连接协议,地址
		broker.addConnector("tcp://localhost:61616");
		broker.start();
	}
}
运行后,可以再通过sender和receiver测试,写法请参照上一篇文章

http://blog.youkuaiyun.com/csdn_kenneth/article/details/79093529
这样的话,最基本的内嵌Broker就启动完成了。

二、工厂模式启动

这种类似代码直接启动,只不过通过工厂模式读取配置文件,再启动。所以需要在resources目录或者项目根目录下新建一个properties文件,这里就叫broker.properties吧,内容是:

useJms=true
persistent=false
brokerName=FactoryBroker
内容就跟代码启动的参数一样,代码是:
package com.tgb.SpringActivemq.test;

import java.net.URI;

import org.apache.activemq.broker.BrokerFactory;
import org.apache.activemq.broker.BrokerService;

public class InnerFactoryBroker {
	 public static void main(String args[]) throws Exception{
	        String uri = "properties:broker.properties";
	        BrokerService broker = BrokerFactory.createBroker(new URI(uri));
	        broker.addConnector("tcp://localhost:61616");
	        broker.start();
	    }
}
这种方式可以通过配置文件更改部分参数

三、Spring启动

Spring是非常强大好用的工具,我们都喜欢将一些配置或者固定启动的东西放在里面,ActiveMQ也不例外。使用Spring首先需要记在依赖:

<!-- Spring Core -->
<!-- http://mvnrepository.com/artifact/org.springframework/spring-core -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>4.1.4.RELEASE</version>
</dependency>

<!-- Spring Context -->
<!-- http://mvnrepository.com/artifact/org.springframework/spring-context -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>4.1.4.RELEASE</version>
</dependency>
然后创建配置xml文件,这里我们建一个beans.xml文件:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean id="broker" class="org.apache.activemq.broker.BrokerService" init-method="start" destroy-method="stop">
        <property name="brokerName" value="SpringBroker"/>
        <property name="persistent" value="false"/>
        <property name="transportConnectorURIs">
            <list>
                <value>tcp://localhost:61616</value>
            </list>
        </property>
    </bean>
</beans>
里面也是配置broker启动的一些基本参数,然后配置都在spring内,代码就很简单了:
package com.tgb.SpringActivemq.test;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class SpringBroker {
	public static void main(String args[]){
        ApplicationContext ctx = new ClassPathXmlApplicationContext("applicationContext.xml");
    }
}
转自: http://blog.youkuaiyun.com/Roy_70/article/details/78773470

<think>好的,我现在需要帮助用户解决如何对ActiveMQ进行JMS压力测试的问题。首先,我得理清楚用户的需求。用户提到了压力测试的方法、工具和最佳实践,所以我的回答需要覆盖这三个方面。 首先,我应该回忆一下ActiveMQ的相关知识。ActiveMQ是一个消息中间件,支持JMS规范,常用于异步通信和解耦应用。压力测试通常是为了评估系统在高负载下的性能表现,比如吞吐量、延迟、稳定性等。用户可能希望确保他们的ActiveMQ部署在高并发情况下仍能可靠运行。 接下来,关于方法部分。压力测试的基本步骤通常包括确定测试目标、准备测试环境、设计测试场景、执行测试、监控与分析结果。针对ActiveMQ,可能需要特别关注消息生产者和消费者的数量、消息大小、持久化设置等。比如,是否需要测试持久化消息与非持久化消息的不同表现,或者不同的持久化存储配置(如KahaDB或LevelDB)对性能的影响。此外,消息确认模式(如自动确认或客户端确认)也会影响性能,需要纳入测试范围。 然后是工具选择。常用的JMS测试工具有JMeter、ActiveMQ自带的性能测试工具,以及像Tsung这样的分布式测试工具。JMeter可以通过JMS Point-to-Point或JMS Publisher/Subscriber采样器来模拟消息的发送和接收。需要指导用户如何配置JMeter的线程组、消息内容、目标队列或主题等。另外,ActiveMQ本身提供了PerfTest工具,可以快速生成生产者和消费者进行压力测试。对于大规模测试,Tsung可能更适合,因为它支持分布式负载生成,能够模拟更多并发用户。 最佳实践方面,应该包括逐步增加负载、监控关键指标、调整配置优化性能、使用持久化时的磁盘性能优化等。比如,用户可能需要调整ActiveMQ的内存配置,如设置适当的最大内存限制,或者配置持久化存储参数,如journalDiskSyncInterval来平衡性能和数据一致性。此外,测试环境的隔离也很重要,确保测试结果不受其他因素干扰。 另外,需要引用用户提供的参考内容。引用[3]提到了KahaDB的配置,其中journalDiskSyncStrategy和journalDiskSyncInterval的设置会影响持久化性能。在测试持久化消息时,用户可能需要调整这些参数,观察对吞吐量和延迟的影响。引用[2]提到ActiveMQ用于多种场景,所以在测试时可能需要模拟不同的应用场景,比如高吞吐量低延迟或者高可靠性需求的情况。 生成相关问题部分,需要考虑用户可能进一步的问题,比如如何优化ActiveMQ配置,或者如何分析测试结果中的瓶颈,以及常见的性能问题有哪些。 现在需要确保回答结构清晰,分点列出方法、工具和最佳实践,同时正确引用提供的参考资料。另外,按照用户要求,所有数学表达式使用$...$格式,但在这个问题中可能涉及较少数学内容,但如果有性能公式可能需要使用。比如计算吞吐量可以用$消息数量/时间$这样的格式。 最后,检查是否符合所有系统级指令,如中文回答、引用标识的正确添加、LaTeX格式的正确性,以及相关问题的生成是否合理。</think>### 如何对 ActiveMQ 进行 JMS 压力测试? #### 一、压力测试方法 1. **明确测试目标** - 确定核心指标:吞吐量(消息/秒)、延迟(毫秒)、系统资源占用(CPU、内存、磁盘I/O)等。 - 区分场景:持久化消息与非持久化消息、点对点(Queue)与发布订阅(Topic)模式[^2]。 2. **设计测试场景** - **生产者与消费者比例**:例如1:1、1:N或N:M,模拟不同并发压力。 - **消息大小**:测试小消息(如1KB)和大消息(如1MB)的性能差异。 - **消息确认模式**:测试自动确认(`AUTO_ACKNOWLEDGE`)与手动确认(`CLIENT_ACKNOWLEDGE`)的影响。 3. **配置 ActiveMQ 参数** - 调整内存限制:修改`activemq.xml`中的`<systemUsage>`配置,例如: ```xml <systemUsage> <systemUsage> <memoryUsage>512 MB</memoryUsage> <storeUsage>100 GB</storeUsage> <tempUsage>50 GB</tempUsage> </systemUsage> </systemUsage> ``` - 持久化优化:如引用[3]中的`journalDiskSyncStrategy`设置,平衡性能与数据一致性。 #### 二、常用工具 1. **Apache JMeter** - 使用 **JMS Point-to-Point** 或 **JMS Publisher/Subscriber** 采样器。 - 配置步骤: - 添加线程组(模拟并发用户)。 - 配置JMS连接工厂(Broker URL、队列/主题名称)。 - 设置消息内容(固定文本或随机数据)。 2. **ActiveMQ PerfTest** - 内置工具,通过命令行快速生成负载: ```bash # 启动生产者(每秒发送1000条消息) ./activemq producer --destination queue://TEST_QUEUE --messageCount 100000 --persistent # 启动消费者 ./activemq consumer --destination queue://TEST_QUEUE --messageCount 100000 ``` 3. **Tsung(分布式测试)** - 支持多节点压测,适用于大规模场景: ```xml <load> <arrivalphase phase="1" duration="300"> <users arrivalrate="1000" unit="second"/> </arrivalphase> </load> <jms> <queue name="TEST_QUEUE"/> <producers> <producer name="producer1" queue="TEST_QUEUE"/> </producers> </jms> ``` #### 三、最佳实践 1. **逐步加压** - 初始阶段:低并发(如100线程),逐步增加至目标值(如5000线程),观察系统瓶颈。 2. **监控关键指标** - **ActiveMQ控制台**:查看队列深度、消费者数量、未确认消息数。 - **系统工具**:使用`top`(CPU)、`iostat`(磁盘I/O)、`netstat`(网络连接)监控资源。 3. **优化配置建议** - **持久化消息**:若使用KahaDB,调整`journalDiskSyncInterval`为更大值(如`2000`毫秒)以提高吞吐量[^3]。 - **非持久化消息**:关闭持久化存储,减少磁盘写入开销。 - **预取限制**:设置`consumer.prefetchSize=100`,避免单个消费者占用过多资源。 4. **结果分析** - 识别瓶颈:若CPU占用高,可能是序列化/反序列化问题;若磁盘I/O高,需优化持久化策略。 - 公式参考:吞吐量 $= \frac{\text{成功处理消息数}}{\text{测试时间}}$,延迟 $= \text{平均消费时间} - \text{平均生产时间}$。 --- ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值