爲什麼ActiveMQ官方不再推薦使用LevelDB
最近在學習mq，雖然已經在使用，但是卻未深入的瞭解，於是閱讀官方文檔的時候發現ActiveMQ官方不再推薦使用LevelDB。ActiveMQ在5.8.0 版本後引入了LevelDB的，並且LevelDB存儲是基於文件的持久性數據庫，可提供比KahaDB更快的持久性。爲什麼ActiveMQ官方不再支持或建議使用levelDB？在網上搜了一大堆終於發現了一篇英文博客給出了原因。以下是其大致內容：
ACTIVEMQ社區棄用LEVELDB - 您需要了解的內容
令人驚訝的是，ActiveMQ社區不再贊成將LevelDB用作其broker的持久性存儲。Christopher Shannon 於2016年11月15日發表以下聲明：
The main reason is that KahaDB continues to be the main focus where bugs are fixed and not much attention is paid to LevelDB. There seems to be several issues with corruption (especially with replication) so I don’t think it should be a recommended store unless the stability is sorted out. Unfortunately nearly every JIRA reported against LevelDB goes ignored.
大概意思是：KahaDB仍然是BUG修復的主要關注點，並且沒有對LevelDB給予太多關注。它似乎有一些問題（特別是在replication），所以並不推薦它作爲存儲方式，除非穩定性能夠得到保證。
爲此ActiveMQ社區迅速作出反應並同意接下來對LevelDB進行進一步的開發工作。
A quick history
LevelDB持久存儲，最初來源於谷歌的BigTable項目，正在積極在許多前沿的應用中使用，其中包括谷歌Chrome和Chromium瀏覽器。它被添加到ActiveMQ5.8版本以解決默認持久性存儲KahaDB的問題。其中大多數問題都與KahaDB使用B-Tree索引和清理效率低下有關。LevelDB的key-caching索引在checkpoint過程中更可靠地執行數據清理。並且在5.9中通過 Zookeeper-powered persistence存儲複製，可提供更快的故障轉移和高可用性模型，而不會出現單點故障。
ActiveMQ的用戶熱烈地接受了這一加強，許多人將他們的持久性配置轉換爲LevelDB。的採用受到額外基礎設施要求的阻礙（實現它需要至少六臺機器），但是大量企業確實利用了改進的HA模型。
採用LevelDB / Zookeeper高可用（HA）模型基礎設施要求很高（實現它需要至少六臺機器），但是大多數公司採用了改進過的HA模型。
Why the change?
儘管有其優點，但LevelDB是一個在ActiveMQ社區之外維護的項目，因此依賴於第三方更新。儘管LevelDB本身是一個可靠的解決方案，但ActiveMQ必須維護自己的客戶端庫以包裝LevelDB，而且在這部分工作的核心提交者不再積極開發ActiveMQ 5.x分支。如果沒有人來改進客戶端適配器，社區就無法充分解決BUG和優化需求。所以社區決定棄用LevelDB並專注於改進KahaDB和ActiveMQ 6.0（Artemis），而不是讓這些問題繼續存在。
What should you do now?
當某個功能被OSS社區棄用時，該功能改進的可能性就會大大降低。ActiveMQ是針對舊版本的LevelDB編寫的，現在它不太可能發生更新。我們建議您儘快遷移LevelDB（包括LevelDB / Zookeeper）。你有一些選擇：
-
回到KahaDB 如果您要從LevelDB / Zookeeper脫機並且需要更快的HA模型故障轉移，請不要忘記您絕不僅限於一個被動實例。您可以讓幾個被動實例爭奪鎖定狀態，這將統計地減少被動代理將變爲活動狀態所需的時間。請記住，自5.11發佈以來，KahaDB已經進行了大量的工作和改進，因此過去遇到的問題可能不再是您的問題。
-
爲KahaDB HA的共享存儲添加冗餘 雖然從技術上講，共享存儲不會消除單點故障，但是爲你的基礎設施使用共享存儲，您可以顯着降低數據丟失的可能性。
-
確保KahaDB正確使用。不要在CIFS / SMB上運行共享存儲，也不要將其保存在任何類型的基於NTFS的文件系統上。通過使用iSCSI協議和GFS2之類的多用戶文件系統，可以獲得最佳吞吐量。如果您在維護精準的鎖定狀態時遇到問題，請務必查看 JDBC Pluggable Storage Locker ，它可以提供更可靠的鎖機制。
-
不要花哨。許多人嘗試使用像GlusterFS，CephFS或DRDB這樣的複製文件系統來複制持久性，但仍然使用主動/被動鎖定機制。雖然在紙面上很好，但這些解決方案在負載下表現不佳，經常失去鎖定狀態並導致無活動或更糟糕的多活動代理可能破壞持久性存儲。
-
請記住，JDBC持久性仍然存在可以使用熟悉的 RDBMS replication concepts集羣，並且可以通過使用連接池（如c3p0）大大提高性能。
-
密切關注Artemis，並準備好在生產就緒時進行切換。
結論
開源解決方案可以快速發展，雖然我們會錯過LevelDB，但社區已經發言，我們必須準備好將我們的關鍵基礎架構向同一方向移動。您仍然可以使用KahaDB實現可靠的故障轉移，社區已經致力於改善KahaDB用戶過去遇到的許多問題。Artemis擁有自己的集羣解決方案，當它準備好時，您可以通過其實現與LevelDB / Zookeeper相同級別的高可用性。
英文一塌糊塗,han~,原文鏈接： activemq-community-deprecates-leveldb-what-you-need-to-know