The persistence mechanism should be based on your application's needs. A closely related concern is going to be failover/availability.
Speaking purely of the speed of message persistence, KahaDB is going to be the fastest; it's tuned specifically for patterns surrounding messaging (writing/reading/discarding). Were you to use something like MSSQL, even with journaling enabled, you're going to give up orders of magnitude (in mgs/sec) in efficiency. This setup works well if you are concerned with publishing high volumes of messages and are willing to leave message recovery up to an admin or some "invented-here" process.
So, why would you choose a different persistence mechanism? High availability.
Re: something like a relational database, it's probably something already available in your enterprise, meaning someone's (hopefully) gone through the effort of clustering and testing disaster recovery. This means you should be able to have a master/slave setup and your messages will be recoverable if a master were to go down. The slave will detect a loss of lock and start using the exact same message store. This setup is ideal if your performance threshold is much lower but you are extremely concerned about up-time and ensuring that you can always publish/subscribe messages.
Regardless, in a well-tuned system, we are talking >= hundreds msgs/sec so performance considerations are likely not going to be your first concern. Should performance really be that crucial, I'd consider looking at something like RabbitMQ, which definitely lends itself well to being extremely efficient at the cost of making high availability more complex to set up.
发布评论
评论（1）
持久性机制应该基于您的应用程序的需求。一个密切相关的问题是故障转移/可用性。
单纯从消息持久化的速度来看，KahaDB 是最快的；它专门针对消息传递（写入/读取/丢弃）的模式进行了调整。如果您使用 MSSQL 之类的东西，即使启用了日志记录，您也会在效率上放弃几个数量级（以毫克/秒为单位）。如果您关心发布大量消息并愿意将消息恢复留给管理员或某些“此处发明”流程，则此设置非常有效。
那么，为什么要选择不同的持久性机制呢？高可用性。
回复：像关系数据库之类的东西，它可能是您的企业中已经可用的东西，这意味着有人（希望）经历了集群和测试灾难恢复的工作。这意味着您应该能够进行主/从设置，并且如果主设备出现故障，您的消息将可以恢复。从站将检测到锁定丢失并开始使用完全相同的消息存储。如果您的性能阈值低得多，但您非常关心正常运行时间并确保始终可以发布/订阅消息，则此设置是理想的选择。
无论如何，在一个经过良好调整的系统中，我们谈论的是 >= 数百条消息/秒，因此性能考虑因素可能不会成为您首先关心的问题。如果性能真的那么重要，我会考虑考虑像 RabbitMQ 这样的东西，它绝对适合非常高效，但代价是使高可用性的设置变得更加复杂。
下面是有关 ActiveMQ 的一些故障转移选项的讨论。我决定使用共享文件主/从设置，并在 SAN 上共享 KahaDB。似乎是一个不错的中间解决方案。
The persistence mechanism should be based on your application's needs. A closely related concern is going to be failover/availability.
Speaking purely of the speed of message persistence, KahaDB is going to be the fastest; it's tuned specifically for patterns surrounding messaging (writing/reading/discarding). Were you to use something like MSSQL, even with journaling enabled, you're going to give up orders of magnitude (in mgs/sec) in efficiency. This setup works well if you are concerned with publishing high volumes of messages and are willing to leave message recovery up to an admin or some "invented-here" process.
So, why would you choose a different persistence mechanism? High availability.
Re: something like a relational database, it's probably something already available in your enterprise, meaning someone's (hopefully) gone through the effort of clustering and testing disaster recovery. This means you should be able to have a master/slave setup and your messages will be recoverable if a master were to go down. The slave will detect a loss of lock and start using the exact same message store. This setup is ideal if your performance threshold is much lower but you are extremely concerned about up-time and ensuring that you can always publish/subscribe messages.
Regardless, in a well-tuned system, we are talking >= hundreds msgs/sec so performance considerations are likely not going to be your first concern. Should performance really be that crucial, I'd consider looking at something like RabbitMQ, which definitely lends itself well to being extremely efficient at the cost of making high availability more complex to set up.
Here's a discussion on some of the failover options with ActiveMQ. I've settled on using a shared file master/slave setup with a KahaDB being shared on a SAN. Seems to be a nice middle-ground solution.