ActiveMq v 5.5 附带默认消息存储配置为 KahaDB 。有没有人在企业级解决方案中使用它？是否应该用 MSSQL 代替？他们每个人都有什么好处？
答案 0 :(得分：11)
持久性机制应该基于您的应用程序的需求。一个密切相关的问题是故障转移/可用性。
纯粹谈到消息持久性的速度，KahaDB将是最快的;它专门针对消息传递（写入/读取/丢弃）模式进行了调整。如果您使用类似MSSQL的东西，即使启用了日记功能，您也会放弃数量级（以毫秒/秒为单位）的效率。如果您担心发布大量消息并且愿意将消息恢复留给管理员或某些“发明在这里”的过程，则此设置很有效。
那么，为什么要选择不同的持久性机制呢？高可用性。
Re：类似于关系型数据库，它可能是您企业中已有的东西，这意味着某人（希望）经历了集群和测试灾难恢复的努力。这意味着您应该能够设置主/从设备，如果主设备发生故障，您的消息将可以恢复。从站将检测到失锁并开始使用完全相同的消息存储。如果您的性能阈值要低得多，但您非常关注正常运行时间并确保始终可以发布/订阅消息，则此设置非常理想。
无论如何，在经过良好调整的系统中，我们正在谈论＆gt; =数百msgs / sec，因此性能考虑很可能不将成为您的首要考虑因素。如果性能真的至关重要，那么我会考虑查看像RabbitMQ这样的东西，这非常适合以高效率设置的高可用性为代价。
这是一个discussion on some of the failover options with ActiveMQ。我决定使用共享文件主/从设置，并在SAN上共享KahaDB。似乎是一个很好的中间解决方案。