手遊頁遊和端遊的服務端本質上沒區別，區別的是遊戲型別。

　　型別1：卡牌、跑酷等弱互動服務端

　　卡牌跑酷類因為互動弱，玩家和玩家之間不需要實時面對面PK，打一下對方的離線資料，計算下排行榜，買賣下道具即可，所以實現往往使用簡單的 HTTP伺服器：

　　登入時可以使用非對稱加密（RSA, DH），伺服器根據客戶端uid，當前時間戳還有服務端私鑰，計算雜湊得到的加密 key 併發送給客戶端。之後雙方都用 HTTP通訊，並用那個key進行RC4加密。客戶端收到key和時間戳後儲存在記憶體，用於之後通訊，服務端不需要儲存 key，因為每次都可以根據客戶端傳上來的 uid 和 時間戳 以及服務端自己的私鑰計算得到。用模仿 TLS的行為，來保證多次 HTTP請求間的客戶端身份，並透過時間戳保證同一人兩次登入金鑰不同。

　　每局開始時，訪問一下，請求一下關卡資料，玩完了又提交一下，驗算一下是否合法，獲得什麼獎勵，資料庫用單臺 MySQL或者 MongoDB即可，後端的 Redis做快取（可選）。如果要實現通知，那麼讓客戶端定時15秒輪詢一下伺服器，如果有訊息就取下來，如果沒訊息可以逐步放長輪詢時間，比如30秒；如果有訊息，就縮短輪詢時間到10秒，5秒，即便兩人聊天，延遲也能自適應。

　　此類伺服器用來實現一款三國類策略或者卡牌及酷跑的遊戲已經綽綽有餘，這類遊戲因為邏輯簡單，玩家之間互動不強，使用 HTTP來開發的話，開發速度快，除錯只需要一個瀏覽器就可以把邏輯除錯清楚了。

　　型別2：第一代遊戲伺服器 1978

　　1978年，英國著名的財經學校University of Essex的學生 Roy Trubshaw編寫了世界上第一個MUD程式《MUD1》，在University of Essex於1980年接入 ARPANET之後加入了不少外部的玩家，甚至包括國外的玩家。《MUD1》程式的原始碼在 ARPANET共享之後出現了眾多的改編版本，至此MUD才在全世界廣泛流行起來。不斷完善的 MUD1的基礎上產生了開源的 MudOS（1991），成為眾多網遊的鼻祖：　型別3：第二代遊戲伺服器 2003

　　2000年後，網遊已經脫離最初的文字MUD，進入全面圖形化年代。最先承受不住的其實是很多小檔案，使用者上下線，頻繁的讀取寫入使用者資料，導致負載越來越大。隨著線上人數的增加和遊戲資料的增加，伺服器變得不抗重負。同時早期 EXT磁碟分割槽比較脆弱，稍微停電，容易發生大面積資料丟失。因此第一步就是拆分檔案儲存到資料庫去。

　　MUDOS採用 C語言開發，因為玩家和玩家之間有比較強的互動（聊天，交易，PK），MUDOS使用單執行緒無阻塞套接字來服此時遊戲服務端已經脫離陳舊的 MUDOS體系，各個公司在參考 MUDOS結構的情況下，開始自己用 C在重新開發自己的遊戲服務端。並且指令碼也拋棄了 LPC，採用擴充套件性更好的 Python或者 Lua來代替。由於主邏輯使用單執行緒模型，隨著遊戲內容的增加，傳統單伺服器的結構進一步成為瓶頸。

第一，選擇什麼樣的架構。

不同的遊戲適用不同的架構。卡牌遊戲架構、MMO遊戲架構、MOBA遊戲架構、FPS遊戲架構

第二，選擇單執行緒還是多執行緒。

作業系統的同步與非同步，程序與執行緒。

第三，如何在遊戲中使用指令碼。

lua語言、lua與C、C++的互動

第四，如何處理網路通訊。

訊息佇列（zmq等）、epoll（libevent等）

兩種處理方式：

一種是跟遊戲伺服器耦合帶一起，遊戲伺服器既處理問落接入相關的邏輯，也處理遊戲邏輯。

一種是把網路通訊部分剝離住來，向遊戲伺服器提供一種以訊息為單位的、非阻塞的、有Qos能力的中間服務，遊戲伺服器看不到網路的細節。

第五，如何處理遊戲通訊協議。

序列化（protobuf等，lua的pbc庫）包頭包體設計

第六，如何設計儲存結構。

sql（mysql）、nosql（redis）、檔案伺服器（hdfs，fastdfs等）

從遊戲來講，所有的線上遊戲通常使用資料庫來儲存使用者資料。通常MMO使用關係型資料庫來儲存資料，後面主要針對MMO進行儲存方式的討論。會有兩種方式：一種是把遊戲的每一個數據物件的屬性看成一個單獨欄位，遵循RDBMS的要求來設計資料庫表和索引，儘量符合3NF。以MMO為例，有帳號表、角色基本資訊表、物品表、裝備表等等，這是一種方式。

還有一種方式更具體，角色的列表類資料儘量採用blob來儲存而不是另一個表。原則是這些列表資料只被角色自身所擁有，就是這個玩家所擁有，其他玩家不會擁有個資料，它的生命週期跟玩家是一致的，不存在其他的交叉擁有情況，技能、物品、裝備、任務、好友等等都屬於這種情況。

優點是儲存表結構簡單，通常幾張表就可以玩一個遊戲，不超過10個。存取互動簡單，角色登入或者推出時通常只需要存取一到二條記錄。同一個角色的資料易於保持一致，易於多版本資料共存。我們把這些資料存到資料庫的時候，會把編碼存到資料庫裡面。所以在資料庫裡面做完的資料可能會不一樣，不過不會影響，它會共存。

這種方式也會有缺點，資料維護工具、客服工具實現相對複雜，需要提供特殊的API來操作資料。如果手上工具是通用的，可能比以前要直白一點。某些型別的統計相對要麻煩一些，有些常用的資料，比如說角色的等級，在這方面可以用一些方式解決你的問題。

第七，如何設計網路同步。

網路同步面臨的主要問題：第一如何減少網路波動對同步的影響；第二如何減少外掛對同步的破壞。

為了解決問題我們有一些基本方法：首先要探測玩家的網路質量；第二在玩家機器與伺服器之間進行時鐘同步；第三基於遊戲特點，設計合理的同步機制。

第八，如何定義效能基準。

可以透過經驗的方式，或者計算的方式來確確定理論上限。網路IO，可以分析，取悅於由遊戲型別、遊戲設計所形成的業務模型，可估算。記憶體，相對來講更簡單，取決於用到的主要資料結構，相對來講更聚焦，更能估算出來支撐多少人。CPU計算能力，其實也不是計算，需要更多對CPU的支撐，簡單的方式，這個遊戲取決於遊戲型別導致的邏輯複雜性。推過這三點，可以有一個目標，大概需要多少人。

（細節：資料結構與演算法，整體：整個遊戲的記憶體管理和網路IO，吞吐量）

第九，如何在不同專案間進行程式碼複用。

把共用的程式碼收歸一個獨立的組織來開發和維護，形成公共元件