關於網絡遊戲開發的數據架構以及事務架構的思考。。。

數據架構包含兩種數據的架構：一種是持久化數據的架構；一種是服務數據的架構。

持久化數據架構意指與持久化相關的數據架構。好比，哪些數據須要持久化，怎麼持久化，在哪裏持久化，何時持久化。對遊戲的服務器來講，是持久層的問題。

服務數據架構指的是與用來服務的數據的架構。是從運行時的角度出發考慮的數據架構。即：我須要怎樣的數據服務。

由於對於遊戲來講，服務器最主要的工做就是在線處理。而「在線處理」的對象即數據。數據是整個服務器的中心。在整個服務器中，除去一些邏輯操做，剩下的就只是數據服務了。

而在數據服務的過程當中，有時須要對數據進行持久化，有時不須要。這就引出了另外一個問題：系統在哪裏？由於，假設系統在某一個時段中歷來未曾進行過或只進行過不多的持久化操做，那麼，我甚至能夠把數據庫或文件系統當作是系統的一個附屬件。

從另外一個角度看，系統的邏輯其實都在應用服務器裏面。這一點在專家系統或規則引擎中其實表現得更爲明顯：邏輯所有在規則引擎中。這時候，我甚至能夠認爲規則引擎就是系統。系統的其他部分，均可以被當作是規則引擎的延伸。好比，一些具體的BEAN類以及對它們的持久化，緩存，事務化，以及負責通訊的消息模塊，負責分佈式實現的底層模塊，狀態管理模塊。

ANYWAY。。。若是系統在應用服務器，那麼毫無疑問的是，數據也應該在應用服務器。至少大部分或主要數據，應該都是放在應用服務器上面或至少應該在應用服務器上存在一個拷貝的。由於，若是每次系統都去數據庫拿數據，那就暗示着數據庫在系統中佔有更重要的地位。而實際上卻並不是如此的。數據庫能作的其實只有持久化。它不能完成任何持久化之外的工做如數據服務。數據服務每每是經過持久層與數據庫進行通訊之後才能往上提供的。所以顯然，數據服務的工做應該放在也的確正在被放在，也只能被放在，系統的持久層上。也就是說，數據服務的工做，不管如何，都是在應用服務器上面完成的。

。。。

服務器內存，服務器磁盤，數據庫或目標文件系統磁盤、內存，以及客戶機磁盤與內存，這些東西，是系統可資利用的全部資源。正確的策略，應該是在權衡用戶體驗的基礎上，最大化本地資源利用率的策略！

既然這樣，爲何不在服務器上作數據緩存呢？將服務器內存轉作其它用途，是否能產生更大的效益比呢？

遊戲的數據常常只是一點點，而每次數據庫查詢，依賴於具體的查詢次序，可能大部分都會須要一次單獨的磁盤IO。若是是這樣的話，緩存在大部分狀況下應該會好於不緩存。

解決方法：

1，對全部的QUERY進行統計分析。看看到底哪些QUERY的頻率高，哪些QUERY的頻率低；

2，對全部的系統資源，包括靜態資源，動態共享資源，動態非共享資源，進行綜合分析。看看哪些能夠被緩存，哪些不能夠被緩存，能夠被緩存的地方，能夠被緩存的時間。

3，內容壓縮（包括動態與靜態內容）；

4，系統優化的目的不在於性能節約，而在於解決高峯問題。提升用戶體驗。