【发布时间】：2011-10-15 09:29:00
【问题描述】：
ActiveMq v 5.5 带有配置为 KahaDB 的默认消息存储。有人在企业级解决方案中使用它吗？应该用 MSSQL 代替它吗？他们每个人都有什么好处？
【问题讨论】：
【发布时间】：2011-10-15 09:29:00
【问题描述】：
持久性机制应该基于您的应用程序的需要。一个密切相关的问题是故障转移/可用性。
单纯从消息持久化的速度来说，KahaDB 会是最快的；它专门针对围绕消息传递（写入/读取/丢弃）的模式进行了调整。如果您使用 MSSQL 之类的东西，即使启用了日志功能，您也会在效率上放弃数量级（以 mgs/sec 为单位）。如果您关心发布大量消息并愿意将消息恢复留给管理员或某些“在这里发明”的过程，则此设置非常有效。
那么，为什么要选择不同的持久性机制呢？高可用性。
Re：类似于关系数据库的东西，它可能已经在您的企业中可用，这意味着某人（希望）经历了集群和测试灾难恢复的努力。这意味着您应该能够进行主/从设置，并且如果主服务器出现故障，您的消息将可以恢复。从站将检测到锁丢失并开始使用完全相同的消息存储。如果您的性能阈值低得多，但您非常关心正常运行时间并确保您始终可以发布/订阅消息，则此设置非常理想。
无论如何，在经过良好调整的系统中，我们所说的 >= 数百条消息/秒，因此性能考虑可能将成为您的首要关注点。如果性能真的那么重要，我会考虑查看RabbitMQ 之类的东西，这绝对有助于提高效率，但代价是使高可用性的设置更加复杂。 p>
这是discussion on some of the failover options with ActiveMQ。我已经决定使用共享文件主/从设置，并在 SAN 上共享 KahaDB。似乎是一个不错的中间解决方案。
【讨论】：
-
谢谢Joshua，很好的回答！我们实际上计划使用 MS SQL 进行持久性，这是在集群上设置的。我们主要关心的不是当时的性能，而是可靠性并保证发送到队列的每条消息都不会丢失，并且始终可供感兴趣的消费者使用。
-
您在 SAN 上设置的 KahaDB 处理/存储的消息量是多少？您系统中消息的平均生命周期是多少？
-
我已经在 SAN 上使用 Kaha 对 ~ 1k/sec 进行了基准测试，但我目前正在开发一个尚未投入生产的新项目。在测试环境中，它的表现非常出色 :-) 在之前的演出中，我们有一些生命周期为几个小时的消息被记录到 MySQL 中，我们的基准测试约为 250/秒。在当前的实现中，我们有意将消息保持在较小的范围内，并将增加工作线程，以使消息的存活时间不会超过几秒钟。
-
顺便说一句，这些基准数字是高度无关的。我已经看到诸如消息大小/消费者数量/内存调整之类的东西将这个数字推向接近 3k/秒。最好的办法是使用一些真实数据进行基准测试，然后查看您的性能下降是否是一个问题。就像你说的，我主要关心的是可靠性。即使在最低点，性能也远高于我的需要。
-
Joshua，当你说 KahaDB 速度快了一个数量级时，你有任何数字证明吗？这很有意义，我完全同意你和你的期望；然而，这是一个相当有力的声明，应该以实际数字为依据。