我什么时候应该在 ActiveMQ 中使用 JDBC 持久性适配器？
阅读 ActiveMQ 文档（我们使用的是 5.3 版本），我找到了有关将 JDBC 持久性适配器与 ActiveMQ 一起使用的可能性的部分。
有什么好处？它是否能提高性能或可靠性？我应该什么时候使用它？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在我看来，如果您想要一个故障转移代理并且无法使用文件系统，您可以使用 JDBC 持久性。 JDBC 持久性比记录到文件系统要慢得多（在我们的测试期间）。对于单个代理，日志文件系统是最好的。
如果您在主动/被动故障转移中运行两个代理，则这两个代理必须有权访问相同的日志/数据存储，以便被动代理可以检测并在主代理发生故障时接管。如果您使用日志文件系统，则文件必须位于某种共享网络驱动器上，使用 NFS、WinShare、iSCSI 等。如果您想消除文件共享，这通常需要更高端的 NAS 设备单点故障。
另一种选择是您可以将两个代理都指向数据库，大多数应用程序已经可以访问该数据库。这种权衡通常是以性能为代价的简单性，因为在我们的测试中，日志 JDBC 持久性速度较慢。
我们在主动/被动代理对中运行 ActiveMQ，并通过 NFS 安装到专用 NAS 设备进行日志持久化，它对我们来说非常有效。我们能够通过我们的系统每秒处理超过 600 条消息，没有出现任何问题。
In my opinion, you would use JDBC persistence if you wanted to have a failover broker and you could not use the file system. The JDBC persistence was significantly slower (during our tests) than journaling to the file system. For a single broker, the journaled file system is best.
If you are running two brokers in an active/passive failover, the two brokers must have access to the same journal / data store so that the passive broker can detect and take over if the primary fails. If you are using the journaled file system, then the files must be on a shared network drive of some sort, using NFS, WinShare, iSCSI, etc. This usually requires a higher-end NAS device if you want to eliminate the file share as a single point of failure.
The other option is that you can point both brokers to the database, which most applications already have access to. The tradeoff is usually simplicity at the price of performance, as the journaled JDBC persistence was slower in our tests.
We run ActiveMQ in an active/passive broker pair with journaled persistence via an NFS mount to a dedicated NAS device, and it works very well for us. We are able to process over 600 msgs/sec through our system with no issues.
嘿，使用日志 JDBC 似乎比仅使用 JDBC 持久性更好，因为日志比 JDBC 持久性快得多。它比仅日志持久化更好，因为您在数据库中拥有额外的消息备份。 Journalled JDBC 还有一个额外的优点，即日志中的相同数据稍后会保存到数据库中，开发人员可以在需要时访问这些数据！
但是，当您将主/从 ActiveMQ 拓扑与日志 JDBC 结合使用时，您最终可能会丢失消息，因为日志中可能有尚未写入数据库的消息！
Hey, the use of journaled JDBC seems to be better than using JDBC persistence only since the journaling is very much faster than JDBC persistence. It is better than just journalled persistence only cos' you have an additional backup of the messages in the db. Journalled JDBC has the additional advantage that the same data in journal is persisted to the db later and this can be accessed by developers when needed!
However, when you are using master/slave ActiveMQ topology with journalled JDBC, you might end up loosing messages since you might have messages in journal that are not yet into the DB!
如果您有重新交付插件策略并使用主/从设置，则调度程序将用于重新交付。
截至目前，调度程序只能在文件数据库上设置，而不能在 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 场景中，如何为重新交付策略设置数据存储，可以被认为是不安全且不受支持的，但至少没有明确记录。
If you have a redelivery plugin policy in place and use a master/slave setup, the scheduler is used for the redelivery.
As of today, the scheduler can only be setup on a file database, not on the JDBC. If you do not pay attention to that, you will take all messages that are in redelivery out of the HA scenario and local to the broker.
https://issues.apache.org/jira/browse/AMQ-5238 is an issue in Apache issue tracker that asks for a JDBC persistence adapter for schedulerdb. You can place a vote for it to make it happen.
Actually, even on the top AMQ HA solution, LevelDB+ZooKeeper, the scheduler is taken out of the game and documented to create issues (http://activemq.apache.org/replicated-leveldb-store.html at end of page).
In a JDBC scenario, therefor it can be considered unsafe and unsupported, but at least not clearly documented, how to setup the datastore for the redelivery policy.