activemq usage
基准测试
新版本：
http://activemq.apache.org/examples.html
${ACTIVEMQ_HOME}/bin/activemq producer
${ACTIVEMQ_HOME}/bin/activemq consumer
老版本的测试工具：1
2
3消费者：ant consumer
生产者：ant producer
设置几百万条消息做压力测试，然后逐步调整heap、perm内存空间大小，慢慢调出最稳定最优的MQ配置
特征
- queue与topic的技术特点对比
| 对比项 | Topic | Queue |
|---|---|---|
| 概要 | Publish Subscribe messaging 发布订阅消息 | Point-to-Point 点对点 |
| 有无状态 | topic数据默认不落地，是无状态的。 | Queue数据默认会在mq服务器上以文件形式保存，比如Active MQ一般保存在$AMQ_HOME\data\kr-store\data下面。也可以配置成DB存储。 |
| 完整性 | 并不保证publisher发布的每条数据，Subscriber都能接受到。 | Queue保证每条数据都能被receiver接收。 |
| 消息是否会丢失 | 一般来说publisher发布消息到某一个topic时，只有正在监听该topic地址的sub能够接收到消息；如果没有sub在监听，该topic就丢失了。 | Sender发送消息到目标Queue，receiver可以异步接收这个Queue上的消息。Queue上的消息如果暂时没有receiver来取，也不会丢失。 |
| 消息发布接收策略 | 一对多的消息发布接收策略，监听同一个topic地址的多个sub都能收到publisher发送的消息。Sub接收完通知mq服务器 | 一对一的消息发布接收策略，一个sender发送的消息，只能有一个receiver接收。receiver接收完后，通知mq服务器已接收，mq服务器对queue里的消息采取删除或其他操作。 |
| 最大区别 | topic是以广播的形式，通知所有在线监听的客户端有新的消息，没有监听的客户端将收不到消息 | queue则是以点对点的形式通知多个处于监听状态的客户端中的一个。 |
测试数据
集群部署
Master-Slave的部署方式, 优点 故障恢复，但是没有负载均衡
- 主从 persistenceAdapter
1
2
3
4
5
6<broker masterConnectorURI="tcp://masterhost:61617" shutdownOnMasterFailure="false">
...
<transportConnectors>
<transportConnector uri="tcp://slavehost:61616"/>
</transportConnectors>
</broker>
- 根据文件系统的排它锁 Shared File System Master Slave
- shared database Master-Slave方式
与shared filesystem方式类似，只是共享的存储介质由文件系统改成了数据库 Replicated LevelDB Store方式
这种主备方式是ActiveMQ5.9以后才新增的特性，使用ZooKeeper协调选择一个node作为master。被选择的master broker node开启并接受客户端连接。
其他node转入slave模式，连接master并同步他们的存储状态。slave不接受客户端连接。所有的存储操作都将被复制到连接至Master的slaves。如果master死了，得到了最新更新的slave被允许成为master。fialed node能够重新加入到网络中并连接master进入slave mode。所有需要同步的disk的消息操作都将等待存储状态被复制到其他法定节点的操作完成才能完成。所以，如果你配置了replicas=3，那么法定大小是(3/2)+1=2. Master将会存储并更新然后等待 (2-1)=1个slave存储和更新完成，才汇报success。至于为什么是2-1，熟悉Zookeeper的应该知道，有一个node要作为观擦者存在。
单一个新的master被选中，你需要至少保障一个法定node在线以能够找到拥有最新状态的node。这个node将会成为新的master。因此，推荐运行至少3个replica nodes，以防止一个node失败了，服务中断。
- 主从 persistenceAdapter
MQ 各Broker节点通过共享文件目录来实现主从的热备，所有的节点都在不断地获取共享目录的排它锁，哪个应用抢到了排它锁，它就成为Master，其他节点为Slave。如果Master节点宕机，它会释放排它锁，从而抢到独占锁的Slave节点可以接管。
因此使用这种主从热备的方式，不仅需要一个多服务器可以共享目录的机制（比如磁盘柜或分布式文件系统），而且文件系统需要支持文件排它锁。
多台节点启动时，先启动的节点获取排它锁，成为Master节点，其他节点成为Slave节点并等待获取共享目录的排它锁。
- Broker Cluster 有集群负载均衡的功能
源码编译
mvn eclipse:eclipse
mvn idea:idea
