activemq总结

最新推荐文章于 2020-02-13 00:07:08 发布

chang_hf

最新推荐文章于 2020-02-13 00:07:08 发布

阅读量293

点赞数

CC 4.0 BY-SA版权

分类专栏： mq

本文链接：https://blog.youkuaiyun.com/chang_li/article/details/88781334

mq 专栏收录该内容

11 篇文章

订阅专栏

消息传输模型

activemq是完全支持jms1.1的，所以它的基本概念和JMS规范是一致的。
消息传送模型支持点对点和发布订阅两种模型：
点对点：使用队列作为通信载体，一条消息只能被一个消费者所使用，未被消费的消息在队列中保留直到被消费或超时。
发布订阅：使用topic作为通信载体，消息通过topic传递给所有的订阅者，在消息发布之后才订阅的用户是收不到该消息的。

安装

通过消息中间件，应用程序或组件之间可以进行可靠的异步通讯，从而降低系统之间的耦合度，提高系统的可扩展性和可用性。在一个服务里调用多个服务，可以先发送消息到消息中间件再投递消息给其他服务。其他服务就可以同步执行了。

部署主要修改两个文件：activemq.xml和jetty.xml，配置的集群brokerName必须相同

消息安全机制

ActiveMQ 如果不加入安全机制的话，任何人只要知道消息服务的具体地址，都可以肆无忌惮的发送、接收消息，所以需要引入消息安全机制。在 conf/activemq.xml 文件中在 broker 标签最后加入以下内容即可：

<plugins>
	<simpleAuthenticationPlugin>
		<users>
			<authenticationUser username="root" password="1234abcd" groups="users,admins"/>
		</users>
	</simpleAuthenticationPlugin>
</plugins>

控制台安全控制

控制台的登录用户名密码保存在 conf/jetty-realm.properties 文件中

# username: password [,rolename ...]
admin: admin, admin
cmcc: cmcc, admin

activemq高可用的原理

解基于 ZooKeeper 和 LevelDB 搭建 ActiveMQ 集群。

高可用的原理：使用zk集群注册所有的 ActiveMQ Broker，只有其中的一个 Broker 可以提供服务，被视为 Master，其他的 Broker 处于待机状态，被视为Slave。如果 Master 因故障而不能提供服务，ZooKeeper 会从 Slave 中选举出一个 Broker 充当 Master。 Slave 连接 Master 并同步他们的存储状态，Slave 不接受客户端连接。所有的存储操作都将被复制到连接至 Master 的 Slaves。如果 Master 宕了，得到了最新更新的 Slave 会成为 Master。故障节点在恢复后会重新加入到集群中并连接 Master 进入 Slave 模式。

连接器

activemq broker的主要作用是为客户端应用提供一种通信机制，并用连接器来描述这种机制。连接器有两种：一种是客户端与broker之间通信的传输连接器；一种是broker之间通信的网络连接器。

传输连接器

用来监听和处理客户端连接。

<transportConnectors>
	<transportConnector name="openwire" uri="tcp://localhost:61616" discoveryUri="multicast://default"/>
	<transportConnector name="ssl" uri="ssl://localhost:61617"/>
	<transportConnector name="stomp" uri="stomp://localhost:61613"/>
	<transportConnector name="ws" uri="ws://localhost:61614/" />
</transportConnectors>

客户端连接 Broker 默认使用基于TCP的 failover 协议。

failover:(tcp://localhost:61616,tcp://remotehost1:61616,tcp://remotehost2:61616)?initialReconnectDelay=100

Failover是一种重新连接的机制，用于建立可靠的传输。其配置语法允许指定任意多个复合的url，它会自动选择其中的一个url来尝试建立连接，如果该连接没有成功，则会继续选择其它的url进行尝试。

网络连接器

用来配置服务器之间的通信
在这里插入图片描述
很多情况下，单台服务器很难支撑海量数据，此时就需要搭建集群，集群broker之间通信需要用到网络连接器。通过这种方式连接在一起的服务器实例之间可共享队列和消费者列表，从而达到分布式队列的目的。
上图中服务器s1和s2通过networkConnector连接，生产者p1发送消息，消费者C3和C4都可以接收到，同样，p3发消息c1和C2也可以接收到。
如果192.168.10.101:61617是s1的地址；192.168.10.102:61617是s1的地址；
需要在s1的activemq.xml中添加

<networkConnectors>
	<!-- <networkConnector name="default-nc" uri="multicast://default"/> -->
	<networkConnector uri="static://(tcp://192.168.10.102:61617)"/>
<networkConnectors>

s2中添加

<networkConnectors>
	<!-- <networkConnector name="default-nc" uri="multicast://default"/> -->
	<networkConnector uri="static://(tcp://192.168.10.101:61617)"/>
<networkConnectors>

以上配置支持复合的uri，如static://(tcp://192.168.10.101:61617，tcp://192.168.10.102:61617)

消息存储

消息的分发方式有两种：持久化和非持久化。如果不设置消息分发方式，activemq会默认发送持久化消息。
非持久化消息常用于发送通知或实时数据中，如果更看重系统性能并且即使丢失一些消息也不会影响业务的正常运作时，可以选择非持久化消息。
持久化消息被发送到broker后，如果当前消息的消费者并没有运行，则该消息会继续存在，只有等到消息被处理并被消费者确认之后，才会从服务器删除。
activemq的消息存储有三种：存储到内存、文件、数据库。
具体使用上，activemq提供了一种插件式的消息存储机制，主要实现了以下几种方式：
Kahadb
一种基于文件并支持事务的消息存储方式。默认的持久化方式
Leveldb
activemq5.6之后推出该持久化引擎，性能高于Kahadb，使用Leveldb将是一个趋势。

JMS2.0 API

public void sendMessageJMS2.0(ConnectionFactory factory,Queue queue,String text){
	try(JMSContext context = factory.createContext();){
		context.createProducer().send(queue,text);
	}catch(JMSRuntimeException e){
		
	}

}