KahaDB

KahaDB 是一個基於檔案的持久化資料庫，它位於使用它的訊息代理程式的本機。它已經針對快速持久化進行了最佳化。自 ActiveMQ Classic 5.4 以來，它是預設的儲存機制。KahaDB 使用較少的文件描述符，並提供比其前身 AMQ 訊息儲存更快的復原速度。

組態

若要使用 KahaDB 作為代理程式的持久化配接器，請將 ActiveMQ Classic 組態如下（範例）

 <broker brokerName="broker">
    <persistenceAdapter>
      <kahaDB directory="activemq-data" journalMaxFileLength="32mb"/>
    </persistenceAdapter>
 </broker>

KahaDB 屬性

屬性	預設值	註解
`archiveCorruptedIndex`	`false`	如果 `true`，在啟動時找到的損毀索引將會被封存（而不是刪除）。
`archiveDataLogs`	`false`	如果 `true`，會將訊息資料記錄移動到封存目錄，而不是刪除它。
`checkForCorruptJournalFiles`	`false`	如果 `true`，會在啟動時檢查損毀的日誌檔案，並嘗試復原它們。
`checkpointInterval`	`5000`	檢查日誌的時間間隔（毫秒）。
`checksumJournalFiles`	`true`	為日誌檔案建立檢查碼。為了讓持久化配接器能夠偵測損毀的日誌檔案，必須要有檢查碼。在 ActiveMQ Classic 5.9.0 之前：預設值為 `false`。
`cleanupInterval`	`30000`	連續檢查之間的時間間隔（毫秒），用於判斷哪些日誌檔案（如果有的話）符合從訊息儲存中移除的條件。符合條件的日誌檔案是指沒有未完成參考的檔案。
`compactAcksAfterNoGC`	`10`	從 ActiveMQ Classic 5.14.0 開始：當啟用確認壓縮功能時，此值控制必須完成多少次儲存 GC 週期，且沒有其他檔案被清除，然後才會觸發壓縮邏輯，以可能將較舊的確認分散在日誌檔案中壓縮到新的日誌檔案中。設定的值越低，壓縮發生的速度可能越快，如果執行太頻繁，可能會影響效能。
`compactAcksIgnoresStoreGrowth`	`false`	從 ActiveMQ Classic 5.14.0 開始：當啟用確認壓縮功能時，此值控制當儲存仍在增長時是否執行壓縮，或者是否僅在儲存停止增長時（由於閒置或達到儲存限制）才執行壓縮。如果啟用，則無論儲存是否有空間或是否處於活動狀態，都會執行壓縮，這可能會降低整體效能，但可以更快地回收空間。
`concurrentStoreAndDispatchQueues`	`true`	啟用將佇列訊息分派給感興趣的用戶端，使其與訊息儲存同時發生。
`concurrentStoreAndDispatchTopics`	`false`	啟用將主題訊息分派給感興趣的用戶端，使其與訊息儲存同時發生。不建議啟用此屬性。
`directory`	`activemq-data`	用於儲存訊息儲存資料和日誌檔案的目錄路徑。
`directoryArchive`	`null`	定義當其中包含的所有訊息都已耗用時，將資料記錄移動到的目錄。
`enableAckCompaction`	`true`	從 ActiveMQ Classic 5.14.0 開始：此設定控制儲存是否會定期壓縮僅包含訊息確認的舊日誌檔案。透過將這些較舊的確認壓縮到新的日誌檔案中，可以移除較舊的檔案，釋放空間，並允許訊息儲存在不達到儲存大小限制的情況下繼續運作。
`enableIndexWriteAsync`	`false`	如果 `true`，則會非同步更新索引。
`enableJournalDiskSyncs`	`true`	確保每次日誌寫入後都進行磁碟同步（JMS 耐久性要求）。此屬性自 ActiveMQ Classic 5.14.0 起已過時。從 ActiveMQ Classic 5.14.0 開始：請參閱 `journalDiskSyncStrategy`。
`ignoreMissingJournalfiles`	`false`	如果 `true`，則會忽略遺失日誌檔案的報告。
`indexCacheSize`	`10000`	快取在記憶體中的索引頁面數。
`indexDirectory`		從 ActiveMQ Classic 5.10.0 開始：如果設定，則會組態 KahaDB 索引檔案（`db.data` 和 `db.redo`）的儲存位置。如果未設定，索引檔案會儲存在 `directory` 屬性指定的目錄中。
`indexWriteBatchSize`	`1000`	在批次中寫入的索引數。
`journalDiskSyncInterval`	`1000`	當 `journalDiskSyncStrategy=periodic` 時執行磁碟同步的時間間隔（毫秒）。只有當自上次磁碟同步以來，日誌發生寫入，或當日誌翻轉到新的日誌檔案時，才會執行同步。
`journalDiskSyncStrategy`	`always`	從 ActiveMQ Classic 5.14.0 開始：此設定組態磁碟同步原則。可用的同步策略清單如下（依安全性遞減和效能遞增的順序）：`always` 確保每次日誌寫入後都進行磁碟同步（JMS 耐久性要求）。這是最安全的選項，但也是最慢的選項，因為它需要在每次訊息寫入後進行同步。這相當於已過時的屬性 `enableJournalDiskSyncs=true`。`periodic` 磁碟將以設定的間隔同步（如果發生寫入），而不是在每次日誌寫入後同步，這將減少磁碟上的負載，並應提高輸送量。當翻轉到新的日誌檔案時，也會同步磁碟。預設間隔為 1 秒。預設間隔提供了非常好的效能，同時比 `never` 磁碟同步更安全，因為資料遺失最多限制在 1 秒內。請參閱 `journalDiskSyncInterval` 以變更磁碟同步的頻率。`never` 永遠不會明確呼叫同步，並且將由作業系統刷新到磁碟。這相當於設定已過時的屬性 `enableJournalDiskSyncs=false`。這是最快的選項，但也是最不安全的選項，因為無法保證何時將資料刷新到磁碟。因此，在代理程式發生故障時可能會發生訊息遺失。
`journalMaxFileLength`	`32mb`	設定訊息資料記錄最大大小的提示。
`maxAsyncJobs`	`10000`	將排隊等待儲存的非同步訊息的最大數量（應與並行 MessageProducer 的數量相同）。
`preallocationScope`	`entire_journal`	從 ActiveMQ Classic 5.14.0 開始：此設定組態如何預先配置日誌資料檔案。預設策略會在首次使用時使用附加程式執行緒預先配置日誌檔案。`entire_journal_async` 會在單獨的執行緒中提前預先配置。`none` 會停用預先配置。在 SSD 上，使用 `entire_journal_async` 可避免在首次使用時因等待預先配置而延遲寫入。注意：在 HDD 上，磁碟的額外執行緒爭用會產生負面影響。因此，請使用預設值。
`preallocationStrategy`	`sparse_file`	從 ActiveMQ Classic 5.12.0 開始：此設定組態當需要新的日誌檔案時，代理程式將如何嘗試預先配置日誌檔案。`sparse_file` - 設定檔案長度，但不會以任何資料填入它。`os_kernel_copy` - 將預先配置委派給作業系統。`zeros` - 每個預先配置的日誌檔案都只包含 `0x00`。
`storeOpenWireVersion`	`11`	決定將 OpenWire 命令封送到 KahaDB 日誌的版本。在 ActiveMQ Classic 5.12.0 之前：預設值為 `6`。代理程式的某些功能取決於較新協定修訂中的 OpenWire 命令中儲存的資訊，如果儲存版本設定為較低的值，這些功能可能無法正確運作。來自高於 5.9.0 的代理程式版本的 KahaDB 儲存在許多情況下仍可由代理程式讀取，但會導致代理程式繼續使用較舊的儲存版本，這表示較新的功能可能無法如預期般運作。對於在 ActiveMQ Classic 5.9.0 之前版本中建立的 KahaDB 儲存，必須手動設定 `storeOpenWireVersion="6"` 才能啟動代理程式而不會發生錯誤。

如需調整鎖定屬性，請參閱可插拔儲存鎖定器中列出的選項。

慢速檔案系統存取診斷記錄

您可以為資料庫更新組態以毫秒為單位的非零閾值。如果資料庫操作速度低於該閾值（例如，如果您將其設定為 500），您可能會看到類似以下的訊息

Slow KahaDB access: cleanup took 1277 | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Classic Journal Checkpoint Worker

您可以透過使用系統屬性來組態用於記錄這些訊息的閾值，並將其調整為您的磁碟速度，以便您可以輕鬆地擷取執行階段異常情況。

-Dorg.apache.activemq.store.kahadb.LOG_SLOW_ACCESS_TIME=1500

多 (m) kahaDB 持久化配接器

從 ActiveMQ Classic 5.6 開始：可以將目的地儲存分散到多個 kahdb 持久化配接器。您何時會這樣做？如果您有一個快速的生產者/消費者目的地和另一個不定期批量耗用的定期生產者目的地，則未耗用的訊息分散在多個日誌檔案中時，磁碟使用量可能會失控。為每個目的地建立單獨的日誌可確保最小的日誌使用量。此外，某些目的地可能很關鍵，需要磁碟同步，而其他目的地可能不需要。在這些情況下，您可以使用 mKahaDB 持久化配接器，並使用萬用字元篩選目的地，就像使用目的地原則項目一樣。

交易

如果目的地分散，則交易可以跨越多個日誌。這表示必須進行兩階段完成，這會產生效能（額外的磁碟同步）懲罰來記錄提交結果。只有當交易中涉及多個日誌時，才會施加此懲罰。

組態

可以獨立組態每個 kahaDB 實例。如果沒有為 filteredKahaDB 提供目的地，則隱含的預設值將符合任何目的地、佇列或主題。這是一個方便的捕捉所有項目。如果找不到符合的持久化配接器，則目的地建立將會失敗並顯示例外狀況。filteredKahaDB 與每個目的地原則共用其萬用字元比對規則。

從 ActiveMQ Classic 5.15 開始，filteredKahaDB 支援名為 usage 的 StoreUsage 屬性。這允許將個別磁碟限制強加於符合的佇列。

<broker brokerName="broker">

 <persistenceAdapter>
  <mKahaDB directory="${activemq.base}/data/kahadb">
    <filteredPersistenceAdapters>
      <!-- match all queues -->
      <filteredKahaDB queue=">">
        <usage>
         <storeUsage limit="1g" />
        </usage>
        <persistenceAdapter>
          <kahaDB journalMaxFileLength="32mb"/>
        </persistenceAdapter>
      </filteredKahaDB>
      
      <!-- match all destinations -->
      <filteredKahaDB>
        <persistenceAdapter>
          <kahaDB enableJournalDiskSyncs="false"/>
        </persistenceAdapter>
      </filteredKahaDB>
    </filteredPersistenceAdapters>
  </mKahaDB>
 </persistenceAdapter>

</broker>

每個目的地的自動持久化配接器

在捕捉所有 (catch all) 的情況下，也就是當沒有明確設定目的地時，請在 filteredKahaDB 條目上設定 perDestination="true"。每個符合條件的目的地都會被分配到各自的 kahaDB 實例。

<broker brokerName="broker">

 <persistenceAdapter>
  <mKahaDB directory="${activemq.base}/data/kahadb">
    <filteredPersistenceAdapters>
      <!-- kahaDB per destinations -->
      <filteredKahaDB perDestination="true">
        <persistenceAdapter>
          <kahaDB journalMaxFileLength="32mb"/>
        </persistenceAdapter>
      </filteredKahaDB>
    </filteredPersistenceAdapters>
  </mKahaDB>
 </persistenceAdapter>

</broker>

在同一個 filteredKahaDB 條目上同時指定 perDestination="true" 和 queue=">" 尚未經過測試。這可能會導致以下例外情況被拋出。
Reason: java.io.IOException: File '/opt/java/apache-activemq-5.9.0/data/mKahaDB/lock' could not be locked as lock is already held for this jvm`