復原容器資料
在此案例中,我們會探索資料復原。 我們認為當容器達到無法處理進一步使用者動作的無效狀態時,資料會損毀。 損毀狀態的結果是容器意外關閉。 通常是暫時性狀態,而且重新開啟時,容器的行為可能會如預期般運作。 在容器在多次重試之後仍無法載入的情況下,我們提供可用來復原資料的 API 和流程,如下所述。
如何流體架構和 Azure Fluid Relay 儲存狀態
流暢架構會定期儲存狀態,稱為摘要,而不需要使用者起始的任何明確備份動作。 如果沒有使用者活動,則每 1 分鐘就會發生此工作流程,如果存在超過 1000 個擱置的作業,則此工作流程會更快發生。 每個暫止的作業大致都會轉譯為尚未摘要的個別使用者動作(選取、文字輸入等)。
Azure 用戶端 API
我們已將下列方法新增至 AzureClient,讓開發人員能夠從損毀的容器復原資料。
getContainerVersions(ID, options)
getContainerVersions
可讓開發人員檢視先前產生的容器版本。
copyContainer(ID, containerSchema)
copyContainer
可讓開發人員從另一個容器的特定版本產生新的卸離容器。
範例復原流程
async function recoverDoc(
client: AzureClient,
orgContainerId: string,
containerScema: ContainerSchema,
): Promise<string> {
/* Collect doc versions */
let versions: AzureContainerVersion[] = [];
try {
versions = await client.getContainerVersions(orgContainerId);
} catch (e) {
return Promise.reject(new Error("Unable to get container versions."));
}
for (const version of versions) {
/* Versions are returned in chronological order.
Attempt to copy doc from next available version */
try {
const { container: newContainer } = await client.copyContainer(
orgContainerId,
containerSchema,
version,
);
return await newContainer.attach();
} catch (e) {
// Error. Keep going.
}
}
return Promise.reject(new Error("Could not recreate document"));
}
重要觀察
我們正在建立新的容器
我們不會復原 (回復) 現有的容器。 copyContainer
會提供新的實例,並將資料從原始容器複製。 在此程式中,不會刪除舊的容器。
已卸離新的容器
新的容器一開始處於 detached
狀態。 我們可以繼續使用中斷連結的容器,或立即附加。 呼叫 attach
之後,我們將取得唯一的容器識別碼,代表新建立的實例。
復原後考慮
在建置復原後案例周圍的使用案例時,以下是幾個應用程式可能想要讓遠端共同作業者再次處理相同容器的考慮。
如果您要只使用流暢容器來建立應用程式資料的模型,當容器損毀時,通訊「連結」會有效中斷。 類似的真實世界範例可能是影片通話,原始作者與參與者共用連結,且該連結不再運作。 考慮到這個觀點,其中一個選項是限制原始作者的復原許可權,並讓他們以與共享原始連結相同的方式共用新的容器連結,在復原原始容器的複本之後。
或者,如果您只針對暫時性資料使用流暢的架構,您一律可以使用自己的真實來來源資料和支援服務來管理更自主的復原工作流程。 例如,多個用戶端可能會開始復原程式,直到您的應用程式有第一個復原的複本為止。 然後,您的應用程式可以通知所有參與的用戶端,以轉換到新的容器。 這很實用,因為任何目前作用中的用戶端都可以解除封鎖參與群組以繼續進行共同作業。 此處的一個考慮是產生備援的成本。