磁碟備份訊息緩衝區是一項功能，使 MQTT 中介者能在用戶訊息佇列超過可用記憶體時，將佇列溢出至磁碟。 部署前先決定是否需要為 MQTT 經紀人提供磁碟備份的訊息緩衝。
Important
此設定會要求您修改代理程式資源。 它只會使用 Azure CLI 或 Azure 入口網站，在初始部署時進行設定。 如果需要代理程式設定變更，則需要新的部署。 若要深入了解，請參閱自訂預設代理人。
磁碟後援訊息緩衝功能用於分散式 MQTT 代理內有效管理訊息佇列。 這些好處包括：
- 高效的佇列管理：在 MQTT 經紀人中，每個訂閱者都與一個訊息佇列相關聯。 訂閱者的訊息處理速度直接影響佇列的大小。 如果訂閱者處理訊息緩慢，或斷線後請求 MQTT 持久會話，佇列可能會超過可用記憶體容量。
- 持續性工作階段的資料保存：磁碟支援的訊息緩衝區功能可確保當佇列超出可用記憶體時，系統會平順地將其緩衝至磁碟。 此功能防止資料遺失並支援 MQTT 持久會話，讓訂閱者在重新連線時能保持訊息隊列完整地恢復會話。 磁碟是當成暫時性儲存體使用，並在記憶體不足時作為溢寫空間。 寫入磁碟的資料不耐用，且在 pod 退出時會遺失。 如果每個後端鏈中至少有一個 pod 仍然運作，整個經紀人不會損失任何資料。
- 處理連線挑戰：雲端連接器被視為具有持續會話的訂閱者，當他們因網路斷線無法與外部系統（如Azure 事件方格 MQTT代理）通訊時，可能會面臨連線困難。 在這種情況下，訊息（PUBLISHes）會累積。 MQTT 代理會智慧地將這些訊息緩衝到記憶體或磁碟，直到連線恢復，確保訊息的完整性。
預設情況下，磁碟備份的訊息緩衝區功能是被停用的。 此時訊息會留在記憶體中，當記憶體使用量達到 訂閱佇列限制時，會對用戶端施加反壓。
Note
MQTT 代理者會將資料寫入磁碟，完全照客戶端接收的樣子，無需額外加密。 保護磁碟對於保護經紀人所儲存的資料至關重要。
配置磁碟備份訊息緩衝區
要設定磁碟備份訊息緩衝區，請在 Broker 資源中編輯該 diskBackedMessageBuffer 區段。 目前，只有在使用 --broker-config-file 命令部署 Azure IoT 操作 時搭配 az iot ops create 旗標，才支援此組態。 欲了解更多資訊，請參閱 Azure CLI 對進階 MQTT 代理配置的支援。
此設定在部署後無法更改。 若要更改磁碟後備的訊息緩衝區設定，請重新部署物聯網運維（IoT）實例。
開始時，請依照 DiskBackedMessageBuffer API 參考準備 Broker 設定檔。
接著，部署帶有 --broker-config-file 標誌的物聯網作業（其他參數為簡潔起見省略）：
az iot ops create ... --broker-config-file <FILE>.json
例如，最簡單的配置只需指定最大尺寸。 在此情況下，會掛載一個emptyDir磁碟區。
maxSize 值會用作 emptyDir 磁碟區的大小限制。 但這個選項因為體積限制，反而是最不受歡迎的選項 emptyDir 。
{
"diskBackedMessageBuffer": {
"maxSize": "1G"
}
}
若要取得更好的磁碟支援訊息緩衝區組態，請指定暫時性磁碟區或持久性磁碟區宣告，以掛載專用儲存體磁碟區供您的訊息緩衝區使用。 例如：
{
"diskBackedMessageBuffer": {
"maxSize": "1G",
"ephemeralVolumeClaimSpec": {
"storageClassName": "foo",
"accessModes": [
"ReadWriteOnce"
]
}
}
}
{
"diskBackedMessageBuffer": {
"maxSize": "1G",
"persistentVolumeClaimSpec": {
"storageClassName": "foo",
"accessModes": [
"ReadWriteOnce"
]
}
}
}
透過調整以下設定來調整經紀商訊息緩衝區選項：
- 設定磁碟區：指定磁碟區宣告範本，以掛載供訊息緩衝區使用的專用儲存磁碟區。
-
選擇儲存類別：利用屬性
storageClassName定義所需的儲存類別。 - 定義存取模式：確認您的磁碟區所需的存取模式。 欲了解更多資訊，請參閱 持久磁碟存取模式。
暫時性磁碟區
暫時性磁碟區是訊息緩衝區的首選。
對於臨時容量，請遵循「 儲存供應商考量事項 」部分的建議。
ephemeralVolumeClaimSpec屬性的值會當成後端鏈之ephemeral.volumeClaimTemplate.spec規格中磁碟區的StatefulSet屬性使用。
例如，要使用容量為 1 GB 的短暫磁碟，請在您的經紀人資源中指定以下參數：
{
"diskBackedMessageBuffer": {
"maxSize": "1G",
"ephemeralVolumeClaimSpec": {
"storageClassName": "foo",
"accessModes": [
"ReadWriteOnce"
]
}
}
}
永續性磁碟區
持久性磁碟區是繼暫時性磁碟區之後，訊息緩衝區的下一個首選。
對於持續性容量，請遵循「 儲存供應商的考量 」部分的建議。
persistentVolumeClaimSpec屬性的值會當成後端鏈之volumeClaimTemplates.spec規格中磁碟區的StatefulSet屬性使用。
例如，要使用容量為 1 GB 的持久磁碟，請在經紀人資源中指定以下參數：
{
"diskBackedMessageBuffer": {
"maxSize": "1G",
"persistentVolumeClaimSpec": {
"storageClassName": "foo",
"accessModes": [
"ReadWriteOnce"
]
}
}
}
emptyDir 磁碟區
emptyDir 磁碟區是在持久性磁碟區之後最不歡迎的選項。
只有在使用有檔案系統配額的叢集時才使用 emptyDir 磁碟區。 欲了解更多資訊，請參閱 檔案系統專案配額標籤。如果沒有啟用這個功能，叢集會定期掃描，不會強制限制，讓主機節點填滿磁碟空間，並將整個主機節點標記為不健康。
例如，若要使用 emptyDir 容量為 1 GB 的磁碟區，請在經紀人資源中指定以下參數：
{
"diskBackedMessageBuffer": {
"maxSize": "1G"
}
}
儲存提供者的考量事項
例如，當你使用像 rancher.io/local-path的儲存提供者時，請考慮你所選擇的儲存供應商的行為。 如果提供者不支援限制，填滿磁碟區會佔用節點的磁碟空間。 這種行為可能導致 Kubernetes 將該節點及所有相關 pod 標記為不健康狀態。 了解你的倉儲供應商在這種情況下的行為至關重要。
Tip
當您指定短暫磁碟申訴（EVC）或持久磁碟申訴（PVC）範本時，您可以選擇儲存類別，這在某些部署情境下增加了彈性。 例如，使用 PVC 模板配置的持久磁碟區會以命令 kubectl get pv形式呈現，這對於檢查叢集狀態非常有用。
如果你的 Kubernetes 節點沒有足夠的本地磁碟空間來放置訊息緩衝區，可以使用像 Azure Blob 儲存體 這類提供網路儲存的儲存類別。 使用本機硬碟的較小 maxSize 值會更好，因為訊息緩衝區能快速存取且不需要耐用度。
Disabled
如果你不想使用磁碟後備訊息緩衝區，就不要在你的經紀人資源中包含該 diskBackedMessageBufferSettings 屬性。 這種行為也是預設的。
磁碟緩衝區與持久性
磁碟備份的訊息緩衝區與 代理持久化 都將資料寫入磁碟，但它們有不同的功能：
| Feature | 磁碟支援的訊息緩衝區 | 持續性 |
|---|---|---|
| Purpose | 當訂閱者佇列過大時，將其從記憶體轉存到磁碟 | 在 Pod 重啟中保留關鍵代理狀態 (保留的訊息、工作階段、訂用帳戶) |
| Durability | 短暫性——當艙體離開時，資料會遺失 | 持久性 — 資料在 Pod 重新啟動後仍可保留 |
| 使用時機 | 處理訊息速度過慢的訂閱者、離線持續性工作階段、與雲端的連線中斷 | 你需要保留訊息或會話狀態才能在經紀商重啟時存活下來 |
| 資料範圍 | 訂閱者佇列中的 PUBLISH 訊息 | 保留的訊息、訂閱者佇列中繼資料、狀態存放區資料 |
| Configuration | 代理資源中的diskBackedMessageBuffer |
部署或執行時的持久性設定 |
Note
磁碟緩衝區與持久化可同時使用。 持久性確保狀態在重新啟動後依然存在，而磁碟緩衝區則防止正常運作時出現記憶體不足的情況。