我應該何時在ActiveMQ中使用JDBC持久性適配器？

Question

閱讀ActiveMQ文檔（我們使用的是5.3版本），我找到了一個關於在ActiveMQ中使用JDBC持久性適配器的可能性的部分。

有什么好處？ 它是否提供了性能或可靠性的任何增益？ 我應該什么時候使用它？

Answer 1

在我看來，如果你想擁有一個故障轉移代理並且你無法使用文件系統，那么你將使用JDBC持久性。 JDBC持久性（在我們的測試期間）明顯慢於對文件系統的日志記錄。 對於單個代理，日志文件系統是最好的。

如果在主動/被動故障轉移中運行兩個代理，則兩個代理必須能夠訪問同一個日志/數據存儲，以便被動代理可以檢測並接管主節點故障。 如果您使用的是日志文件系統，那么這些文件必須位於某種共享網絡驅動器上，使用NFS，WinShare，iSCSI等。如果您想要消除文件共享，通常需要更高端的NAS設備。單點故障。

另一個選擇是您可以將兩個代理指向數據庫，大多數應用程序已經可以訪問該數據庫。 由於在我們的測試中記錄的JDBC持久性較慢，因此權衡通常是以性能為代價的簡單性。

我們在主動/被動代理對中運行ActiveMQ，並通過NFS掛載到專用NAS設備進行日志持久化，它對我們非常有效。 我們能夠通過我們的系統處理超過600 msgs / sec，沒有任何問題。

Answer 2

嘿，使用日志JDBC似乎比使用JDBC持久性更好，因為日志記錄比JDBC持久性快得多。 它比僅僅記錄持久性更好cos'你在db中有一個額外的消息備份。 Journalled JDBC具有額外的優勢，即日志中的相同數據將在以后持久保存到db，開發人員可以在需要時訪問它！

但是，當您使用帶有記錄的JDBC的主/從ActiveMQ拓撲時，您可能最終會丟失消息，因為您可能在日志中還有尚未進入數據庫的消息！

Answer 3

如果您具有重新傳遞插件策略並使用主/從設置，則調度程序將用於重新傳遞。

截至今天，調度程序只能在文件數據庫上設置，而不能在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方案中，因此可以將其視為不安全且不受支持，但至少沒有明確記錄，如何為重新傳遞策略設置數據存儲。