有人使用LevelDB store进行ActiveMQ消息持久化吗？

目前，我们正在使用KahaDB store在ActiveMQ中进行消息持久化，目前效果良好。
根据ActiveMQ5.6的发行说明，

LevelDB

提供了增强的性能。
有人尝试过使用LevelDB吗？如果有，你能提供利弊吗？

请查看此链接： leveldb和kahadb之间有一个小的比较

---

我目前正在一个具有高消息吞吐量的系统上进行测试，我已经看到了更好的结果。我还需要看看它是否稳定，但到目前为止还不错。

仅供参考：这里有一个链接，指向

缺点：

• 这是一家全新的商店，所以可能仍有一些漏洞
• LevelDB索引偶尔需要“压缩”，这可能会暂停新的写入
• 您不能像使用KahaDB一样，删除索引并从数据文件中重建它
• KahaDB更优雅地处理磁盘损坏，尽可能恢复并丢弃损坏的记录

优点：

• 附加磁盘访问模式提高了旋转磁盘的性能
• 磁盘同步比磁盘同步少
• 每个存储的邮件需要插入的索引项更少
• 将邮件从磁盘加载到内存所需的索引查找更少
• 使用Snappy压缩减少索引项的磁盘大小
• 数据日志的可选快速压缩
• 发送到复合目的地只在磁盘上存储一次消息
• 更快、更频繁的数据文件GCs
• 具有一个可自我复制到“从属”代理以确保消息级别HA的功能

---

我们已经在NFS上使用levelDB存储两个月了，现已投入生产（配置了标准文件锁故障切换）。在过去的几周里，我们已经有过几次损坏的存储，日志中没有错误。。。只是队列堆积如山，吞吐量非常低。要解决这个问题，我们唯一能做的就是扔掉商店，重新开始

---

因此，我们现在又回到了旧而可靠的KahaDB商店。

对于LevelDB的大多数性能声明似乎都是空洞的声明。它应该支持高并发性读取，但多线程测试显示没有并发性增益

---

（相比之下，对于跨多个CPU的读取，LMDB显示出完美的线性性能增益。）

我对AMQ性能进行了广泛的测试，但在测试中未能获得LevelDB与KahaDB之间的任何统计上的显著差异：

能否请您记录一个错误，并提供有关您的设置的任何信息，以重现此错误：感谢您提及KahaDB损坏的文件处理。我们对损坏的leveldb文件有一些问题。