10
閱讀ActiveMQ文檔（我們使用的是5.3版本），我找到了關於在ActiveMQ中使用JDBC持久性適配器的可能性。何時應該在ActiveMQ中使用JDBC持久性適配器？
有什麼好處？它是否提供任何性能或可靠性的增益？我應該什麼時候使用它？
A
回答
9
在我看來，如果你想擁有一個故障轉移代理並且你不能使用該文件系統，你將使用JDBC持久性。 JDBC持久性（在我們的測試期間）明顯比日誌記錄到文件系統慢。對於單個代理，日誌文件系統是最好的。
如果在主動/被動故障轉移中運行兩個代理，則兩個代理必須有權訪問相同的日記/數據存儲，以便被動代理可以在主服務器出現故障時檢測並接管。如果您使用的是日誌文件系統，那麼這些文件必須位於某種共享網絡驅動器上，使用NFS，WinShare，iSCSI等。如果您想消除文件共享，通常需要更高端的NAS設備單點故障。
另一種選擇是您可以將兩個經紀人指向數據庫，大多數應用程序已有權訪問該數據庫。在性能價格方面，權衡通常是簡單的，因爲在我們的測試中日誌記錄的JDBC持久性較慢。
我們在一個主動/被動代理對中運行ActiveMQ，並通過NFS掛載到專用NAS設備進行日誌記錄，並且它對我們非常有用。我們能夠通過我們的系統處理超過600個信息/秒，沒有問題。
2
嘿，使用日誌JDBC似乎比使用JDBC持久性更好，因爲日誌記錄比JDBC持久性要快得多。這比僅僅支持持久性要好，因爲你有額外的db中的消息備份。已編輯的JDBC具有的額外優點是，日誌中的相同數據稍後會保存到數據庫中，並且可以在需要時由開發人員訪問！
但是，當您使用帶有日記的JDBC的主/從ActiveMQ拓撲時，最終可能會丟失消息，因爲日記中可能還有尚未進入數據庫的消息！
1
如果您有適當的重新傳送插件策略並使用主/從設置，則調度程序將用於重新傳送。
截至今天，調度程序只能在文件數據庫上進行設置，而不能在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場景中，因此它可以被認爲是不安全和不受支持的，但至少沒有明確記錄，如何爲重新傳輸策略設置數據存儲。
Yeap，那正是我的經驗。 在我們的測試中，JDBC持久性比日誌選項慢了許多倍。 謝謝 – 2009-12-03 17:53:35