DB Cache 理論和理解

DB Cache數據的結構

遊戲數據庫中存儲的數據以tree爲單位進行處理，該tree由node組成。

每個node具有父母、子女關係,每個node具有名稱-值對,即property field。

加載的數據樹的最上位node root node 的 table name 和 child node 的 table name 必須不同。

DB Cache 資料存取類型

DB cache的基本使用方法是獨家加載和處理數據，ProudNet DB系統提供以下類型的訪問。

- 壟斷加載

爲了避免競爭狀態,DB cache系統只允許將相同的數據加載到1個DB cache client上,這被稱爲壟斷加載(exclusive load)。

DB Cache System在已經有一個DB Cache Client獨佔時，如果新的DB Cache Client提出獨佔請求，以前的DB Cache Client就會收到轉讓獨佔權的請求，並且可以接受或拒絕。 此時,如果以前的DB Cache Client將數據Unload,新的DB Cache Client將獲得壟斷權。

(1) 單方面更改數據

進行單方面數據更改時，數據會立即反映到DB緩存的內存中，這種更改過一段時間後，在數據庫中進行實際記錄，即數據緩存。 由於單方面數據更改處理會立即返回，因此在更改數據的例程中不會出現等待時間。 因此，無需在數據變更後等待結果完成的過程。

不需要像下面的例程那樣unlock then lock過程。

UpdateSomeData()
{
    lock(X);
    ...
    unlock(X);
    UnilateralUpdateSomeData(X);
    lock(X);
    ...
    unlock(X);
}

(2) 更改請求響應數據

請求響應型數據變更是請求響應型,與單方面數據更改相反。 DB cache client向DB cache server要求請求響應型數據變更，並將其實際記錄在數據庫中，通過DB cache client確認記錄成功與否。

請求響應型數據變更並不是真正的cache，但更改不會反映在 DB cache 中，直到實際記錄成功，從而減少由於 DB Constraints 導致記錄失敗的機率。 當請求響應型數據變更通常用於在網路遊戲中建立玩家角色時，這會禁止重名。

(3) 存取非專有數據

單方面數據更改和請求響應型數據變更僅限於獨家加載的數據。

但是，有時您想要讀取或寫入已經在其他 DB 緩存中獨家加載的數據。 在網絡服務器上閱覽播放器角色的信息,或者在付費道具結算服務器上向播放器角色的包中添加或變更道具時,也有需要閱覽或變更正在運營工具上登錄的播放器的角色信息的情況。

存取非專有數據是用於此的功能。

所有存取非專有數據都對DBConstraints具有抗性，儘管它們不是立即響應的，因爲它們以請求響應型數據變更的方式運行。 另外，如果非壟斷性地更改數據，則進行壟斷加載的DB cache client會收到數據被其他地方更改的通知。

DB直接存取DB cache處理的數據

由DB快取載入和處理的資料樹的資料狀態保持比DB中的資料狀態更新的狀態。 這是因為資料先記錄在DB快取中，然後再記錄在DB中。

因此，如果使用者將資料與資料庫快取處理的資料樹分開直接記錄在資料庫中，則可能會出現不必要的錯誤，因為資料庫中的資料暫時過時。

這和data race condition是類似的問題。

ProudNet在DB中想要直接操作DB cache處理的data tree時,爲了避免data race condition,提供數據隔離功能(data isolation),即使直接訪問DB,也不會發生data race condition,完全解除用戶想要的data tree的使用權。

使用方法如下。

• 對於DB中需要直接訪問的data tree,通過Proud.CDbCacheClient2.RequestIsolateData(X)呼叫,X將被隔離處理,如果X已經加載,則可以卸載。

• Proud.IDbCacheClientDelegate2.OnDeisolateDataSuccess(X)回電後，可以安全地訪問DB中的X。

• 如果 X 是隔離的， DB 緩存不能加載 X 。

• 完成對 X 的數據庫訪問後， 調用 Proud.CDbCacheClient2.RequestDeisolateData() 方法解除隔離 。