以下对在使用ActiveMQ集群出现的存储问题进行记录总结
ActiveMQ集群模式下是怎么存储的呢？
1.leveldb
具体怎么搭集群，这里就不说了，网上随便搜一下就有文章。
简单说说，就是MQ集群中有很多的ActiveMQ节点，每个节点都有自己的leveldb存储，通过zookeeper选举master,其它从节点同步master节点的数据然后保存到自己的leveldb中做数据持久化。
这样存储会有什么问题呢？
leveldb是将所有queue的消息存在一起的，也就是一个日志文件的，只有当这个日志文件的大小达到某个阈值的时候，才会创建新的日志文件。
日志文件的删除策略是：当这个日志文件里的所有消息都被消息了，这个日志文件就可以删除了
试想一个这样的场景：有100个queue,其中99个queue的消息消费都挺快的，剩余1个queue的消息量很少，偶尔发几条，但是它的消费特别慢，在某个特定的场景才会去消费，这种情况会引发什么问题呢？就因为这一个queue的消息没消费，导致日志文件不能删除，当其他queue的消息量大时，就会产生很多的日志文件，导致磁盘空间得不到释放，最终撑爆机器。（可能有的人会觉得这种场景太罕见了，但是如果是专门做消息平台的，这个问题就很可能会遇到）
怎么解决呢？简单嘛，加大磁盘空间啥，反正磁盘成本也不高。
当然，肯定没这么简单啥，加大了磁盘空间又会引发新的问题：当日志文件的个数累加到七八百个时候，ActiveMQ发消息和消息的速度就会大大降低，因为打开了太多的文件句柄。
目前这个问题还没有很好的解决方案，可以将这个queue消息发到另外一个临时的节点上，然后等磁盘空间释放后，在从临时节点把消息给发回来。
2.kahadb
基于kahadb搭建集群的基本原理就是：因为KahaDB底层就是文件系统，基于KahaDB搭建集群就是将KahaDB当成一个共享文件系统，集群中的服务器启动时对共享文件加锁，加锁成功的就是Master,其他的就是slave,只有Master能够对外提供服务。
这种模式，由于只有一个master,也可以对外提供服务，所以在某些极端情况会出现丢消息：
1.当从服务器挂了时，主服务器依然可用，在从服务器挂了期间，主服务器存储设备出现问题，从服务器挂掉期间的消息就全部丢失了。
2.主从同步的速度受限于网络，如果网络抖动，还没同步到从服务器时主服务器出问题，这时的消息也会丢失。
