遊戲服務端開發一

資料儲存伺服器

遊戲中的資料大致分為靜態配置資料和動態的玩家資料。這裡主要討論玩家資料儲存的解決方案。

雖然遊戲應用的寫操作要多於讀操作，但是加入快取層仍然有其必要性。多個應用伺服器啟動時從資料庫讀取資料會在瞬間給資料庫造成巨大壓力，如果將相對靜態的資料以檔案的形式放在應用伺服器本地，可以避免這個問題，但同時帶來的另乙個問題是靜態資料的維護成本增加。

引入靜態資料快取層，避免集中訪問對資料庫產生的壓力，同時方便對資料的維護。資料在被修改後即可通知曾讀取過資料的所有的應用伺服器。

另一方面，執行一次sql

語句，不論是單個還是批量都一次相當耗時的通訊，因為客戶端在收到資料庫伺服器的響應之前程式流是被阻塞的，這是典型的

cpu因為等待

io而空閒。雖然設計者大可以使用非同步執行緒來執行

sql，但非同步使用

cpu就可以不再精打細算嗎？

如果把同步玩家資料由執行sql

變為一次應用伺服器和資料儲存伺服器的應用協議通訊，情況就會不一樣，設計者可以將之設計成非同步的，甚至是有問無答的。

快取玩家資料用以支援同步玩家資料的應用協議，記憶體永遠比磁碟快。此外玩家下線並不會立即將之從快取中移除，而是將其歸入乙個離線玩家集合，因為相逢的人會再相逢，離線的人很有可能會短時間內再上線。

將玩家分類（登入時線路/門派

/性別）快取，可以縮短查詢時間。

在之前的乙個專案中設計思想是玩家資料（屬性，物品）有更新發生就會產生一條sql語句，定時地一次性批量執行這些

sql。這裡有兩個值得改進的地方。

1對於乙個玩家有多個

sql，而且這些

sql會覆蓋上乙個

sql執行的結果，無謂的加大資料庫負擔，增大連線占用時間。

2如果玩家人數眾多，行為多，將在在短時間內大量難以消化的

sql，對記憶體對儲存系統的造成隱患。

應用程式使用源記憶體進行業務計算（面向客戶端的讀寫功能），cache

子系統分類管理源記憶體的控制代碼（面向資料儲存的唯讀功能）。

cache

子系統定時將玩家資料結構做一分快照同步到資料伺服器或者當更新的玩家人數達到乙個閥值時做及時同步，另凡涉及到玩家交易的資料更新要做同步並留下業務

log。

上述設計沒有考慮應用伺服器的人數負載。如果遊戲應用負載很大的話，在定時同步的時間點可能會產生大量難以消化的sql

。我們說每隔一定時間會將玩家的資料同步到儲存系統，但是沒有說所有玩家的資料都在同一時間點進行同步。我們有理由相信玩家在職業上的分布是大體相似的，所以先同步和尚，再同步道士，再同步乞丐，最後解決捕快，也不失是一種解決的方法。

這個思路同時適用於應用伺服器和資料儲存服務向下層的寫入應用。

遊戲服務端開發 一