遊戲緩衝的小改進

     一款大型網路（網頁）遊戲。我認為主要有兩個方面影響遊戲的效能。

 

     1，資料庫讀取，影響遊戲邏輯模組代碼的執行時間。在多並發下，影響到了遊戲整體效能

　　要縮小這個影響。可以事先將資料庫中的資料讀到記憶體裡。遊戲運營期間，讀取的是記憶體的資料。這樣，就在一定程度上繞過了資料瓶頸。通常，都是將商城等這樣的資料預告讀入記憶體。因為商城裡的出售的商品資料，一般是比較固定不變的。維護起來方便。

　　這個方案可以再度改善。可以將玩家資料也讀入記憶體。

　　至於，在遊戲啟動其間是否載入所有玩家資料進入記憶體，或是按照分布方式，老化機制讀取維護。這一方面我還沒有花時間去思考學習。如果有在這方面有高見的朋友，望不吝賜教。鑒於實體記憶體條市場價格不是很昂貴，這種以記憶體空間換取程式效能的方式是可取的。

     2，網路通訊，畢竟是一個IO操作，也是會影響遊戲效能的一大關鍵因素。

　　在在談到關於構架一款高效能遊戲時，我們同事間偶爾會談論關於將聊天模組獨立於另一台伺服器的方案。如此，在類似於這樣高頻資料通訊。對伺服器效能比較底層將是一款比較大的考驗。通常各位大牛會考慮用C＋＋，而放棄java編寫服務端代碼。因為C＋＋相對於底層，在這方面比java效能好。

　　但是，不管用什麼語言去編寫服務端代碼。通訊的最佳化是我們總是要考慮的。

　　從第一天開始寫遊戲代碼，我就開始思考前台用戶端資料緩衝的架構。並把想法實現到了代碼裡。既在通訊方面的最佳化是，能不通訊的，盡量的不通訊。能小量資料傳送的，儘可能的用小量資料傳遞。

　　這方面，可以在遊戲通訊協定上最佳化，就是上面提到的“能小量資料傳送的，儘可能的用小量資料傳遞”，這是架構的另一大方面。今天暫不和大家討論這一點。

　　還有一點可以做到最佳化。既以上所提到的“資料緩衝的架構。並把想法實現到了代碼裡。既在通訊方面的最佳化是，能不通訊的，盡量的不通訊”。一般是用在用戶端做緩衝做到這一點。

　　今天我想和朋友們分享關於用戶端緩衝與伺服器資料同步的一個小小方案。

　　如果我們將用戶端接收到資料都緩衝起來。比如A玩家查看所有玩家列表，當看到第14頁有3條資料（假設1頁有10條）。如果將這頁的內容緩衝在了用戶端。過會，又有新玩家B註冊進遊戲了。由於A中已經緩衝了14頁記憶體，後來加上B玩家，雖然也在14頁，但A不重新整理則是看不到了。如果用A註冊，廣播所有玩家更新緩衝。這種做法不明智。畢竟不是郵件資料這種性質。對於此類資料。用戶端的緩衝，有兩個解決方案。

　　第一，用戶端需要再次翻頁到13頁，會向伺服器申請，並提交當前資料頁的版本號碼，伺服器根據比較版本號碼，決定給不給用戶端發送資料。但伺服器對於版本號碼的比較，是一個比較煩瑣的事。今後有時間再來考慮這個方案。

　　第二，還有一種辦法比較簡單，就是我接下來一段時間會採用的。

　　用戶端按頁進行緩衝，假如剛才的A玩家讀取了14頁的資料，由於只有3條，不足一頁，所以不緩衝。下次翻頁再次請求資料。伺服器端不需要版本比較，直接發送資料。如果用戶端收到的資料是滿上一頁的，則緩衝，下次讀取，直接讀緩衝。

　　辦法很簡單，做法也很簡單。將用戶端資料按頁緩衝就是了。

 

　　

　　本文中有錯誤會可以更好的改進的地方，希望朋友們多多指教。一起學習一起進步。