如何設計屬於本身的遊戲服務器（二）

不少遊戲都在花費大篇幅講解網絡模型，其實，這些對於你而言，徹底沒必要關心，現有的模型一大把。就好比PSS，你用它就能夠忽略網絡IO模型，直接負責處理到達的數據和如何迴應就好了。
那麼，咱們來講說遊戲服務器的一些細節。
以端遊爲例，如今的端遊能夠說各類花哨，各類副本，公會戰，任務，鍛造，跑商等等等等。。系統繁多。
可是請靜下心來，撥開那些層層迷霧。
其實遊戲服務器沒什麼神祕的，就幾個專業的算法可能比較耗一些功夫，好比，AOI，好比，尋路，好比，腳本。
先不要去想這些實現手段，首先要知道，咱們有什麼武器？
不管任何遊戲，都分爲兩種消息，一種是客戶端主動提交給服務器的，一種是服務器主動下發給客戶端的。簡單的來講，無外乎，一去一回，一回一去，一去，一回。
一去一回，就是客戶端主動發起一個事件，須要獲得服務器的迴應。
一回一去，就是服務器有事件發生了，須要通知客戶端。
一去，客戶端只是通知服務器一個事件。不須要回應。
一回，服務器通知客戶端一個事件，不須要回應。
很好，先明確這個概念，也就是，服務器和客戶端之間的通信，是一種或者幾種事件機制。
網上一些說遊戲服務器的文章，說每秒吞吐幾萬個數據包如何如何性能了得，我很想問問，實際的遊戲服務器，你真須要這麼大的服務器吞吐量嗎？
固然，你能夠說，像Dota，星際那種實時對戰遊戲，對數據包有及是毫秒級的要求，畢竟人家講的是DPS。可是，我想說的是，大多數遊戲，根本不須要這麼多的數據包吧。
不少時候，設計是能夠優化的，若是我是一個玩家，1秒鐘內在地圖點擊了10個地點，若是控制的小人都去那些地方，光服務器和客戶端來回耗時就會不少。先不談網絡優劣的問題。問題是，這些數據有必要服務器去處理嗎？
（1）必須先明確，什麼是無效的數據和事件。
對，什麼是無效的數據。無效的數據很空泛，其實從用戶行爲分析，你能夠分析出用戶在你的遊戲中，哪些是屬於無效操做。客戶端主動屏蔽這些無效操做。好比，1秒鐘我換了10個方向，那麼我只須要取得最後一個防線便可。也就是前9個我徹底能夠忽略。固然，客戶端須要處理一下這爲展現。再好比，我反覆的打開了商店界面，由於商品在必定時間內是穩定的，那麼徹底能夠過一段時間同步一下商店數據便可。不用每次都發送請求。
不過從實際運行來看，並非說客戶端屏蔽了這些無效操做就能夠了。服務器同樣要作這些動做，由於你沒法約束數據包行爲。或許外掛，特殊狀況，會有垃圾數據包到來。
就比如，你把服務器看作一個餐廳，進來一批食客，其中保不齊有周圍餐館派來砸場的，你的廚師就那麼幾位，有些人故意點了一大桌子不吃，害的你的廚師忙死，卻讓真正想吃飯的食客等不及而離場，這明顯是得不償失的。因此，你的服務器須要一個經驗豐富的"侍者"，它能夠分辨食客的點餐餐單，那些是有明顯問題的，好比，有i一個食客連續點了10個宮保雞丁，你就要看看這個食客究竟是要幹什麼。
服務器的這個"侍者"，就是要對客戶端上來的各類"餐單"(數據包)進行初步過濾，起碼，不能讓那些明顯處問題的餐單來佔據你的服務器資源。
從設計的角度來說，我能夠對某一個用戶的數據包進行歸類，某一類數據包不能短期出現屢次。若是出現了且非要回復，只取得在這段時間內最新的一個便可，其餘的同類數據包丟棄。
我這裏要講一個設計關鍵原則，就是必定要保證優質的遊戲玩家享受最好的服務，而那些質量差的玩家，不多會爲你的遊戲多付費，因此，想辦法保證一切優質客戶很重要，服務器的資源也應當傾向於此。
（2）那些是必須如今返回的，哪些是能夠等一會再返回的。
不少網絡講遊戲服務器的文章，更加更關注的技術的實現細節，而實際上，咱們跳出這些繁複的代碼。仔細分析一下？哪些是 "當即"和"暫緩"。
仍是拿餐廳舉例，通常人氣火爆的餐廳，大多不會一個客戶點一個菜馬上抄一個。抄完了在看下一個餐單。
而是，會等那麼一小會，看這一小會會不會有相同的餐單到達，一鍋燴，一塊兒出盤。
別小看餐廳的學問，好好的和他們學習，你會學到很是多的服務器設計知識。並且，好的餐廳每每能教你怎麼作一個偉大的服務器。
那麼，你看，這些餐單，實際是能夠"等那麼一會也沒什麼大問題的"。
而有些則是必須立刻返回的，好比，食客下了餐單，你必須交給廚房之後迅速的告知食客，你的餐單已經到達了廚房。
拿遊戲中的一個實際功能來講，玩家發出一個"行走"指令，實際上，客戶端已經能夠行走了。服務器只要返回一個收到了便可。只要定時計算服務器和客戶端的玩家點位是否匹配便可。有差距拉回來。
而對於服務器，徹底能夠等那麼一等，好比，等1秒，這1秒鐘全部的玩家行走指令都收齊了，一個定時器一口氣算出來。
或許就有那麼討厭的玩家，連續1秒鐘換了3,4個終結點。
換個話說，有哪些餐館討厭的食客，剛下單就要換菜品，猶豫不決，若是餐廳沒有這個"緩衝"時間，那麼作出來的菜誰去消費？明顯是浪費食物。（浪費服務器資源）
還有就是，遊戲中的交易，必須時時反饋，交易成功了仍是失敗了，必須第一時間讓玩家知道。
餐館也是這樣，結帳的時候，食客提出刷卡，若是服務器員說你等會，等到一波食客一塊兒刷，人家不罵你纔怪。
因此，從設計上來說，要學會細分這兩項，仔細想清楚，會給你的服務設計帶來很是好的體驗提高。
（3）如何規劃數據流
仍是拿網上的文章來講，不少文章在遊戲服務器上推崇多線程。
多線程，對於初學者總以爲會很快，而當實際使用的時候，老是發現各類數據須要再不一樣的線程裏同步的問題，形成大量的數據鎖，代碼複雜了不說，本身估計之後都難以看懂。
因此，這裏要說，組織多線程是一門學問。
仍是那個餐廳。
我有10個桌子的食客，其中6個點了甜點，有4個點了魚肉，有7個點了小吃。
若是讓一個廚師去作這些菜。確定會慢的出奇。
看看現實中是怎麼解決的？有甜點師，有配菜師，有幾個大廚，分別應對不一樣的菜品。同時去作，各自互不干擾。作魚的不用知道食客點了多少甜品。
那麼，遊戲服務器是怎麼表現呢？
我有一個玩家進了一個場景，那麼理論上，一個場景內，只有這個場景內的玩家會對他產生影響。別的場景均可以不用知道這個玩家的存在。
那麼，若是把這個場景看作一個廚師，那麼"玩家"實際就是一個個餐單。不一樣的廚師去料理不一樣的餐單便可。菜能夠同時上，也能夠一個個上。
實際上，90%的多線程數據鎖，是徹底能夠用這種或者那種數據模式去解決的。

大天然教會了咱們如何生存，也教會了咱們，如何用這些規則造福別人。因此，不少程序設計上很難的問題，實際你的生活早就教給了你解決方法，關鍵是，要學會去發現，去思考。