• <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模式非常贊  回復  更多評論
              

            国产精品久久久久久久久鸭| 伊人色综合久久| 久久亚洲私人国产精品vA | 波多野结衣久久精品| 亚洲国产成人久久一区久久| 久久夜色精品国产网站| 大美女久久久久久j久久| 久久亚洲AV永久无码精品| 亚洲国产精品无码久久一线| .精品久久久麻豆国产精品| 久久久噜噜噜久久| 久久99国产综合精品免费| 亚洲精品WWW久久久久久| 久久精品国产久精国产思思| 色综合久久天天综线观看| 97精品国产91久久久久久| 综合久久一区二区三区| 久久精品9988| 久久精品国产亚洲AV大全| 久久精品免费全国观看国产| 99国内精品久久久久久久| 精品熟女少妇AV免费久久| 国产一区二区精品久久凹凸| 精品少妇人妻av无码久久| 伊人 久久 精品| 国产成人久久精品二区三区| 久久人人爽人人爽人人AV | 亚洲欧美精品一区久久中文字幕| 国产精品久久久久久久| 亚洲精品无码久久千人斩| 久久久久久国产精品美女 | 亚洲午夜久久久精品影院| 精品久久亚洲中文无码| 久久精品国产精品亚洲人人| 久久久久久久尹人综合网亚洲 | 欧美精品国产综合久久| 精品国产综合区久久久久久 | 99国产欧美久久久精品蜜芽| 久久久婷婷五月亚洲97号色| 久久久久久精品免费看SSS| 亚洲中文字幕伊人久久无码|