ProudNet.Cn
WebsiteProud ConsoleLanguage
  • 🌐ProudNet
    • ProudNet 簡介
    • 下載並安裝
      • ProudNet授權認證方法
      • AMI
    • 項目設定
      • C++
      • C#
      • Mac Xcode
      • Linux
      • Unity3D
        • iOS 建置
      • Unreal Engine 4
      • 運行 PIDL 編譯器
    • 使用 ProudNet
      • 伺服器和客戶端
        • 如何使用伺服器
        • 如何使用客戶端
      • RMI
        • 如何使用RMI
      • PIDL
        • 如何使用PIDL
      • 事件處理
      • 通訊訊息
      • P2P 通訊
        • 如何使用P2P通訊
    • 活用 ProudNet
      • 如何使用它
      • 性能小貼士
    • 在 ProudNet 中使用 DB
      • DB Cache System ver.2
        • DB Cache 理論和理解
        • DB Cache 安裝和網絡設置
        • DB Cache 伺服器和用戶端
        • DB Cache 使用與活用
          • DB Cache 活用法
      • ADO API
      • ODBC API
    • ProudNet 實用程式
  • ProudNet note
    • 技術說明
      • 對主循環的理解
      • 配置服務器防火牆
      • 加密和解密
      • 發生錯誤時的應對事項
      • 錯誤信息列表
      • 同步角色位置
      • 客戶端與服務器通信
      • MiniDump (Error Dump System)
      • [1.6 版本] 服務器間 LAN 通訊器
    • 詞彙表
    • Sample 例題
  • 🌐ProudChat
    • 介紹及使用指南
    • 下載 SDK
      • C++
      • C#
      • Unity3D
      • Unreal Engine 4
Powered by GitBook
On this page
  • DB Cache數據的結構
  • DB Cache 資料存取類型
  • - 壟斷加載
  • DB直接存取DB cache處理的數據
  1. ProudNet
  2. 在 ProudNet 中使用 DB
  3. DB Cache System ver.2

DB Cache 理論和理解

PreviousDB Cache System ver.2NextDB Cache 安裝和網絡設置

Last updated 1 year ago

目前的 ProudNet DB 系統只在 Windows 上運行。

遊戲數據庫的特點是,交易規模較小,但訪問次數較多,且大部分數據都是反覆加載和保存,ProudNet數據庫系統通過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系統提供以下類型的訪問。

訪問類型
應用示例
Cache 與否
即時回調
是否需要專有加載
內部處理方式

單方面更改數據

遊戲過程中玩家角色資訊頻繁更改

YES

YES

YES

先向存儲器緩存,然後向DB緩存write

更改請求響應數據

創建一個具有唯一名稱的玩家角色

NO

NO

YES

寫入DB後如果成功則緩存在記憶體中

存取非專有數據

從網頁伺服器購買付費物品

NO

NO

NO

寫入DB後如果成功則緩存在記憶體中

- 壟斷加載

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);
}

單方面數據更改無條件地應用於DB cache的內存,但更改可能無法反映在數據庫中設置DB Constraints的記錄中。

因此,即使未設置或設置了 DB Constraints,也建議在確定的情況下使用它。 在通常的網絡遊戲中,關於玩家和世界地區客體的數據庫客體可以安全地使用單方面數據更改。

(2) 更改請求響應數據

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

(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() 方法解除隔離 。

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

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

🌐
將用戶賬戶信息保存到DB的示例
用於將用戶帳戶信息存儲在DB中的表格結構
Server 1 擁有的 Gamer X 是由 Server 2 壟斷裝入的狀態
Data race condition by DB cache vs. DB access
Data isolation
Data Isolation Usage
競爭狀態
DB Constraints