MQ使用经验

ActiveMQ是apache的一个开源JMS服务器，不只具有标准JMS的功能，还有不少额外的功能。公司里引入ActiveMQ后，ActiveMQ成里咱们公司业务系统中最重要的一个环节。全部应用都经过jms集成，若是ActiveMQ出了故障，整个系统就瘫痪了。所以，头对ActiveMQ的性能，可靠性，以及如何正确使用，是很是的关心的，而我就被指派来作关于ActiveMQ的调研，本文对此作了些总结。

1 使用jms须要注意的问题

一下所述的问题，不只是对ActiveMQ，对于其余的JMS也同样有效。

1.1 不要频繁的创建和关闭链接

JMS使用长链接方式，一个程序，只要和JMS服务器保持一个链接就能够了，不要频繁的创建和关闭链接。频繁的创建和关闭链接，对程序的性能影响仍是很大的。这一点和jdbc仍是不太同样的。

1.2 Connection的start()和stop()方法代价很高

JMS的Connection的start()和stop()方法代价很高，不能常常调用。咱们试用的时候，写了个jms的connection pool，每次将connection取出pool时调用start()方法，归还时调用stop()方法，然然后来用jprofiler发现，通常的cpu时间都耗在了这两个方法上。

1.3 start()后才能收消息

Connection的start()方法调用后，才能收到jms消息。若是不调用这个方法，能发出消息，可是一直收不到消息。不知道其它的jms服务器也是这样。

1.4 显式关闭Session

若是忘记了最后关闭Connection或Session对象，都会致使内存泄漏。这个在我测试的时候也发现了。原本觉得关闭了Connection，由这个Connection生成的Session也会被自动关闭，结果并不是如此，Session并无关闭，致使内存泄漏。因此必定要显式的关闭Connection和Session。

1.5 对Session作对象池

对Session作对象池，而不是Connection。Session也是昂贵的对象，每次使用都新建和关闭，代价也很是高。并且后来咱们发现，原来Connection是线程安全的，而Session不是，因此后来改为了对Session作对象池，而只保留一个Connection。

2 集群

ActiveMQ有强大而灵活的集群功能，可是使用起来仍是会有不少陷阱。

2.1 broker cluster和 master-slave

ActiveMQ能够作broker的集群，也能够作master-slave方式的集群。前者能在多个broker以前fail-over和load-balance，可是在某个节点出故障时，可能致使消息丢失；然后者能实时备份消息，和fail-over，可是不能load-balance。broker cluser的方式，在一个broker上发送的消息能够在其它的broker上收到。当一个broker失效时，客户端能够自动的转到别的broker上运行，多个broker能够同时提供服务，可是消息只存储在一个broker上，若是那个broker失效了，那么客户端直到它从新启动后才能收到该broker上的消息，假如很不幸，那个broker的存储介质坏了，那么消息就丢失掉了。
Master-slave方式中，只有master提供服务，slave只是实时的备份master的数据，因此消息不会丢失。当master失效时，slave会自动升为master，客户端会自动转到slave上工做，因此能fail-over。因为只有master提供服务，因此不能将负载分到多个broker上。
其实单个broker的性能已是至关的惊人了，在咱们公司的机器上能达到每秒收发4000个消息，每一个消息4K字节这样的速度，足够公司目前的须要了，而公司并不但愿丢失任何数据，因此咱们选择使用master-slave模式。

2.2 多种master-slave模式

master-slave也有多种实现方式。它们的不一样只是在共享数据和锁机制上。
在ActiveMQ急群中， broker有着Master和Slave两种身份，其中，Slave至关于Master的热备份，会一直复制Master的信息，当Master挂掉以后由最新复制Master的Slave接管。目前ActiveMQ官网给出如下三种方式实现Master和Salve之间纤细的复制：
a) 共享文件系统
b) 共享数据库(JDBC)
c) 借助Zookeeper（Replicated LevelDB Store）（这里须要强调如下，在单机模式或者共享文件系统中，ActiveMQ会选择使用KahaDB而不是LevelDB，官网说因levelDB不支持延迟或者计划任务消息而被弃用)。

2.2.1 Pure master-slave

Pure master-slave，显示的在配置文件中指定一个broker作为另外一个broker的slave。运行时，slave同过网络自动从master处复制数据，同时在和master失去链接时自动升级为master。当master失效，slave成为master后，若是要让原先的master从新投入运行，须要停掉运行中的slave(如今升级为master了)，手动复制slave中的数据到master中。再从新启动master和slave。这种方式最简单，效率也不错，可是只能有两台作集群，只能fail-over一次，并且须要停机恢复master-slave结构。

2.2.2 JDBC master-slave

这种方式不须要特殊的配置，只要让全部的节点都把数据存储到同一个数据库中。先拿到数据库表的锁的节点成为master，一旦它失效了，其它的节点得到锁，就能够成为master。由于数据经过数据库共享，放在一个地方，不须要停机恢复master-slave。这种方式，须要额外的数据库服务器，若是数据库失效了，那么就全失效了，并且速度不是很快。咱们在用mysql测试时，并无成功，master失效后，其余的节点始终没有升级成slave，多是数据库配置的问题。

2.2.3 Share file master-slave

这种方式相似于前者，也不须要特别的配置，只是经过共享文件系统来共享数据，靠文件锁实现只有一台成为master。共享文件系统的方式有不少，咱们测试了nfs v4 (v3有bug，不行)， 最终在稳定性，效率等方面不是很满意，多是经过网络太慢了。

测试过众多master-slave模式后发现，pure方式管理起来麻烦，jdbc方式成本高，效率低，share file方式须要高性能的共享文件，都有缺点。鉴于单台activeMQ很可靠，而咱们的基础平台组愿意用硬件备份，最终仍是决定不用master-slave了，也不用broker cluster，就用单台，经过硬件冗余保证数据不会丢失，并找另一台刀片机作冷备，在主服务器失效时顶替。