什么时候应该在ActiveMQ中使用JDBC持久性适配器?

在我看来,如果您想要一个故障转移代理,并且不能使用文件系统,那么您将使用JDBC持久性。JDBC持久性(在我们的测试期间)比记录到文件系统要慢得多。对于单个代理,日志文件系统是最好的。

如果您在主动/被动故障转移中运行两个代理,那么这两个代理必须能够访问同一日志/数据存储,以便被动代理能够在主代理发生故障时检测并接管。如果您使用的是日志文件系统,则文件必须位于某种类型的共享网络驱动器上,使用NFS、Winshare、ISCSI等。如果要将文件共享作为单一故障点消除,这通常需要更高端的NAS设备。

另一种选择是,您可以将两个代理都指向数据库,大多数应用程序都可以访问该数据库。权衡通常是以性能为代价的简单性,因为日志记录的JDBC持久性在我们的测试中较慢。

我们在一个主动/被动代理对中运行activemq,并通过一个NFS挂载到一个专用的NAS设备来记录持久性,它对我们来说非常有效。我们能够通过我们的系统处理超过600毫秒/秒,没有任何问题。

嘿,日志JDBC的使用似乎比JDBC持久性要好,因为日志记录比JDBC持久性快得多。它比只记录持久性要好,因为在数据库中有额外的消息备份。日志JDBC还有一个额外的优点,即日志中的相同数据在以后被持久化到数据库中,开发人员可以在需要时访问这些数据!

但是,当您将主/从ActiveMQ拓扑与日志JDBC一起使用时,可能最终会丢失消息,因为日志中可能有尚未进入数据库的消息!

如果您有一个重新交付插件策略并使用主/从设置,那么调度程序将用于重新交付。

从今天起,调度器只能在文件数据库上设置,而不能在JDBC上设置。如果您没有注意到这一点,那么您将从HA场景中获取所有正在重新传递的消息,并将这些消息本地传递给代理。

https://issues.apache.org/jira/browse/AMQ-5238 是Apache问题跟踪器中的一个问题,它要求为schedulerdb提供JDBC持久性适配器。你可以投一票让它成为现实。

事实上,即使是最顶级的AMQ HA解决方案(LevelDB+ZooKeeper),调度器也会被从游戏中删除并记录下来,以创建问题。( http://activemq.apache.org/replicated-leveldb-store.html 在页面末尾)。

因此,在JDBC场景中,可以认为它是不安全的、不受支持的,但至少没有明确记录如何为重新交付策略设置数据存储。