• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            戰魂小筑

            討論群:309800774 知乎關注:http://zhihu.com/people/sunicdavy 開源項目:https://github.com/davyxu

               :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
              257 隨筆 :: 0 文章 :: 506 評論 :: 0 Trackbacks

            最近參加了一個大服務器架構討論活動, 記錄下心得

            概述

            游戲客戶端采用Cocos2dx-Lua的純Lua編寫邏輯, 服務器采用Golang作為開發語言

            游戲類型類似于COC,因此無需選服. 需要使用大服務器架構進行處理

            數據庫

            采用Mongodb做持久存儲, redis做跨服通信數據交換

            使用UCloud的云技術, 省去了煩人的運維工作

            通信及協議

            客戶端和服務器通訊使用HTTP短連接, 基于json的數據封包協議

            服務器間大量使用Golang自帶的json+rpc進行通信

            服務器類型

            服務器類型大致分為邏輯服務器,戰斗服務器, 中心服務器

            邏輯服務器

            邏輯服務器負責日常邏輯及公共邏輯處理(好友, 公會)

            1個邏輯服務器對應一個區, n個區均使用Ucloud云Mongodb進行數據存儲

            戰斗服務器

            戰斗服務器是一個集群, 集群會返回一個負載最低的服務器返回使用

            戰斗服務器通過cgo技術與客戶端C++/lua的戰斗邏輯進行邏輯復用, 在此技術上進行

            戰斗邏輯的校驗

            中心服務器

            客戶端登陸前, 在中心服務器這里獲得可登陸的邏輯服務器地址, 同時做一個負載均衡

            短連接

            評價

            由于操作系統的技術趨于穩定, 同時, 手游的弱交互型導致的游戲架構趨于簡單. 因此網絡負載不再是游戲服務器技術的瓶頸. 從經驗看來, 游戲服務器技術, 更重要的是還是看數據庫的選型及處理方式. 

            雖然Mongodb的性能上不如內存數據庫. 但是從存儲安全性上要比個人搭建的內存數據庫簡單, 安全

            外加上云技術的引用, 性能的瓶頸和運維的技術復雜度迎刃而解

            Redis用于跨服數據交互那是再好不過的數據中介了, 保證速度和穩定性, 絕對不是造輪子能比擬的

            短連接在手游上處理起來比長連接簡單一些, 無需做斷線重連. 服務器的底層也是由Golang的框架庫保證質量的. 因此負載毫無問題. 服務器對內及對外均使用json進行數據交換, 簡化了協議處理. 也方便了調試

            json rpc的性能損耗對于整個邏輯的處理來說均可以忽略不計

            posted on 2015-07-21 10:30 戰魂小筑 閱讀(5150) 評論(8)  編輯 收藏 引用 所屬分類: 網絡 服務器技術Golang

            評論

            # re: 大服務器架構討論 2015-07-21 10:43 小強哥
            各個邏輯服務器之間的玩家有數據交互嗎?如果有,那么只是通過redis之間從mongo里把數據取出來,中間沒有一個統一的數據服務來做一些同步操作嘛?  回復  更多評論
              

            # re: 大服務器架構討論 2015-07-21 10:44 戰魂小筑
            @小強哥
            每個區之間會有跨服邏輯, 跨服通過redis交互數據
            同步操作都是服務器之間自己完成, 無需中間服務器進行同步  回復  更多評論
              

            # re: 大服務器架構討論 2015-07-22 14:52 QQ:79039039-8
            請問對于全局狀態,也是redis來緩存?
            應該需要全局鎖操作吧,數據是否有多份呢?

            否則,這個架構本身還是存在單點故障/瓶頸吧。(當然要分析目標玩家數量)。

            我也在成都,下次有討論叫上我啊~  回復  更多評論
              

            # re: 大服務器架構討論 2015-07-22 14:53 戰魂小筑
            @QQ:79039039-8
            加我的群討論吧

            redis只是兩個服務器間某種邏輯的數據交換. 其實一般這種交換對數據的時效性要求不是那么及時. 鎖沒必要的  回復  更多評論
              

            # re: 大服務器架構討論 2015-08-31 09:49 freeeyes
            服務器開發實際上有兩種模式。
            一種是你說的Actor模式,實際上,這種模式的關鍵是極度信賴內部網絡,雖然邏輯可以分散,但是在設計上,你必須做到數據消息狀態的解耦,否則,會給未來調試和測試帶來很多的問題。
            無狀態數據,一般選擇http類似協議(因為現成,簡單高效,可以和腳本語言方便整合,適合移動網絡),一般情況下,Gate模式是比較受歡迎的。數據在入口驗證,所有的邏輯依靠后面負載的各種服務器(一般的情況可以選擇部分中間件作為消息傳遞手段,比如thrift,ice,tao等)。這種分布的基礎在于數據的流向并不確定,你不知道數據的下一個命中點在哪個服務器,所以對于持久化的數據(比如用戶信息,玩家數據等)必須支付更多的IO成本去做維護統一。那么,在這樣的模式下,服務器架構的穩定性,就被壓在IO上了。在排錯過程中,你必須確認數據在IO上的流動,從而需要支出部分維護架構的開發成本。并且最大的保證內部IO的穩定,當模塊變多和設計上的耦合需要,隨著功能的復雜,模塊間交互的增加,未來維護成本會較高。
            一種是面向數據狀態的負載,這種相對比較好理解,比如前幾年的一些MMO游戲,這種模式開發的依賴不是IO,同樣可以支持Gate模式,但是,數據流的方向是指定的,也就是說,服務器的處理不以單獨一個功能模塊劃分,而是以一組的形式存在。一組服務在一臺主機上,這種模式依賴的是內存的效率。一般是采用共享內存節省數據交換的成本。這種狀態的模式,很難做到精確的負載均衡,而更加考驗的是,你的駕馭邏輯的能力,這里必須強調的前期的數據組織和開發能力。
            兩種模式的比較,實際是你信任IO還是信任內存。你把維護放在需求開發后還是需求開發前的問題。
            在實際開發過程中,沒有萬能藥,最關鍵的是,如何利用已有的資源去解決需求提出的問題。開發的關鍵,是把復雜變簡單。
            最關鍵的是,架構是為人服務的,關鍵是要做到隔離性,獨立性,可維護性以及可替換性。  回復  更多評論
              

            # re: 大服務器架構討論 2015-08-31 09:56 戰魂小筑
            @freeeyes
            非常給力的評論!  回復  更多評論
              

            # re: 大服務器架構討論 2015-08-31 14:21 freeeyes
            有興趣可以一起研究可服用的服務器架構?  回復  更多評論
              

            # re: 大服務器架構討論 2015-12-01 17:04 mmocake
            Actor模式非常贊  回復  更多評論
              

            青青热久久综合网伊人| 久久99国产精品尤物| 欧美精品丝袜久久久中文字幕 | 久久93精品国产91久久综合| 9191精品国产免费久久| 精品久久久一二三区| 久久综合给合久久国产免费| 26uuu久久五月天| 新狼窝色AV性久久久久久| 国产精品女同一区二区久久| 亚洲AV无一区二区三区久久 | 色综合久久88色综合天天| 香蕉久久影院| 国产精品99久久不卡| 香蕉久久av一区二区三区| 久久久久这里只有精品 | 久久久久一区二区三区| 久久久国产视频| 久久国产精品无码网站| 国产高潮国产高潮久久久| 精品久久久久久久国产潘金莲| 国产成人综合久久精品尤物| 精品久久久久久无码中文字幕一区| 欧美伊人久久大香线蕉综合69 | yy6080久久| 欧美午夜A∨大片久久| 91精品国产色综久久| 国产精品9999久久久久| 狠狠精品久久久无码中文字幕| 亚洲色欲久久久久综合网| 欧美777精品久久久久网| 99久久这里只有精品| 成人国内精品久久久久一区| 久久久久99精品成人片欧美| 久久综合噜噜激激的五月天| 男女久久久国产一区二区三区| 欧美大香线蕉线伊人久久| 国产精品久久久久久吹潮| 91视频国产91久久久| 亚洲嫩草影院久久精品| 久久精品亚洲乱码伦伦中文|