• <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 戰魂小筑 閱讀(5151) 評論(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模式非常贊  回復  更多評論
              

            亚洲欧洲久久av| AV无码久久久久不卡蜜桃| 欧美日韩精品久久久久| 麻豆久久久9性大片| 97久久超碰国产精品旧版| 色综合久久最新中文字幕| 久久人人爽人人精品视频| 乱亲女H秽乱长久久久| 久久国产精品二国产精品| 一本色道久久综合亚洲精品| 成人久久久观看免费毛片| 久久综合偷偷噜噜噜色| 91精品国产91热久久久久福利| 久久SE精品一区二区| 精品久久久久久无码人妻蜜桃| 亚洲国产欧洲综合997久久| 中文字幕成人精品久久不卡| 伊人久久大香线蕉AV色婷婷色| 成人午夜精品久久久久久久小说| 亚洲综合久久久| 亚洲国产精品综合久久一线| 狠色狠色狠狠色综合久久| 乱亲女H秽乱长久久久| 2021国产精品久久精品| 久久综合给合综合久久| 国产女人aaa级久久久级| 国产情侣久久久久aⅴ免费| 久久精品成人欧美大片| 久久人人爽人人爽人人片AV东京热| 激情综合色综合久久综合| 91精品观看91久久久久久| 18岁日韩内射颜射午夜久久成人| 久久99精品久久久久久久久久| 老色鬼久久亚洲AV综合| 日韩乱码人妻无码中文字幕久久| 亚洲中文字幕无码久久2017| 99久久精品免费看国产一区二区三区| 一本久久综合亚洲鲁鲁五月天| 亚洲中文字幕伊人久久无码| 一本一本久久a久久精品综合麻豆| 亚洲精品美女久久久久99小说 |