阅读 ActiveMQ 文档(我们使用的是 5.3 版本),我找到了有关在 ActiveMQ 中使用 JDBC 持久性适配器的可能性的部分。
有什么好处?它是否提供了性能或可靠性方面的任何收益?我应该什么时候使用它?
阅读 ActiveMQ 文档(我们使用的是 5.3 版本),我找到了有关在 ActiveMQ 中使用 JDBC 持久性适配器的可能性的部分。
有什么好处?它是否提供了性能或可靠性方面的任何收益?我应该什么时候使用它?
在我看来,如果你想拥有一个故障转移代理并且你不能使用文件系统,你会使用 JDBC 持久性。JDBC 持久性(在我们的测试期间)比日志记录到文件系统要慢得多。对于单个代理,日志文件系统是最好的。
如果您在主动/被动故障转移中运行两个代理,则这两个代理必须有权访问相同的日志/数据存储,以便被动代理可以检测并在主节点发生故障时接管。如果您使用的是日志文件系统,则文件必须位于某种共享网络驱动器上,使用 NFS、WinShare、iSCSI 等。如果您想消除文件共享,这通常需要更高端的 NAS 设备单点故障。
另一种选择是您可以将两个代理都指向大多数应用程序已经可以访问的数据库。权衡通常是以性能为代价的简单性,因为在我们的测试中,日志式 JDBC 持久性较慢。
我们通过 NFS 挂载到专用 NAS 设备在具有日志持久性的主动/被动代理对中运行 ActiveMQ,它对我们来说非常有效。我们能够通过我们的系统处理超过 600 条消息/秒,没有任何问题。
嘿,日志 JDBC 的使用似乎比仅使用 JDBC 持久性更好,因为日志比 JDBC 持久性快得多。这比仅记录持久性要好,因为您在数据库中有额外的消息备份。Journalled JDBC 还有一个额外的优势,即日志中的相同数据稍后会持久化到数据库中,开发人员可以在需要时访问它!
但是,当您使用带有日志 JDBC 的主/从 ActiveMQ 拓扑时,您可能最终会丢失消息,因为您可能在日志中有尚未进入数据库的消息!
如果您有重新交付插件策略并使用主/从设置,则调度程序用于重新交付。
截至今天,调度程序只能在文件数据库上设置,而不是在 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 场景中,因此它可以被认为是不安全和不受支持的,但至少没有明确记录如何为重新传递策略设置数据存储。