• <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>

            Sheppard Y

            keep thinking keep coding.

            了解云風的skynet

            2016-07-11 日更新 
            此篇博客已經遷移到新博客,并做行文檢查和優化排版:
            http://blog.clawz.me/2014/01/16/14-cloudwu-skynet-research/



            (PS開始應用《暗時間》里提到的理論,將skynet用自己的話來總結并寫下來,這樣能充分思考并轉述為自己的記憶線索)


            一、skynet設計的理解

            (一)單個skynet節點

            (1)愿景

                充分利用多核。最初想法是多進程。像咱們nodejs里多核就只能是多進程了,因為每個nodejs進程是單線程的。

                多進程是遵循unix設計哲學,工具鏈形式,分拆進程的形式來分拆模塊,減少復雜度和耦合性,方便編程及維護。

                后來云風他們發現lua做為嵌入式腳本,寫邏輯時很好用的,反正如何都要用lua,而且lua提供了沙盒,這樣多進程可以變為單進程多個沙盒,這樣綜合了多進程和單進程多線程的優勢。多線程里共享資源,在同一進程地址空間,訪問更高效。


            (2)核心功能(門房?)

                很精簡,僅解決一個問題。

                skynet里不實現具體游戲邏輯,后者些放到一個一個動態庫里(so文件)。skynet將這些so注冊到自己里邊,每個so一個永不重復的id,類似于數據庫的autoincreament??疵枋鲞@個id是skynet自己運行時當次維護的,而不是模塊配置好終身的id。模塊的永久有效唯一標示為名字,skynet提供了名字服務,可以給每個模塊取一個易讀的名字。


            (3)核心不解決什么問題

                skynet主張所有服務在同一OS進程協作完成。核心里就沒管跨機通訊,單個服務的崩潰和重啟也沒管,云風表示這些應該由上層處理,他有責任暴露錯誤,而不是隱藏。

                這個設計的原因,游戲和操作系統不一樣,操作系統默認不信任任何進程,各進程崩潰什么的不應影響其他進程,所以某個進程掛了,他就安葬它,而其他進程美好的生活。單游戲是為玩家服務的,某個環節出錯都有可能造成玩家利益混亂,所以那里錯了就整個流程(服務器)掛掉吧。沒有必要讓出錯模塊被隔離開,而其他模塊卻繼續提供服務導出未預知行為。

                上邊說的東西應該上層考慮,使用lua的沙盒就能做策略隔離。


            (4)skynet運行時邏輯流

                skynet負責且只負責將一個數據包從一個服務發送到同一進程的另一個服務里。發送服務直接調發送API,skynet收到數據包后,調用接受者服務的注冊的callback,即發給了接受者服務。

                skynet保證在各模塊初始化時、每個獨立的callback調用時,都是相互線程安全的。這樣編寫服務的人就不需要考慮多線程的任何問題了,只需專心處理給他的一個個數據包。

                PS:天龍的場景lua有點像這里的單個服務。不知天龍的跨線程切場景情況在這里也可以給簡化為單線程?(回頭看源碼再研究這個問題)


            (5)消息調度

            TODO


            (6)gate和connection

            TODO


            (二)skynet集群

                集群里最多支持255個skynet節點,每個skynet節點有一個id,成為harbor id。這個id是集群層面指定,可以人為分配,也可以由一個中央服務器協調分配。

            (1)集群間通信

                skynet核心層紙負責在往外發消息時在source字段上加上自己的harbor id。而集群間的通信,是由單獨的harbor服務來做的。skynet將是往集群其他節點發的消息,就轉發到harbor內。harbor會跟集群內跟自己結識的skynet的harbor簡歷tcp鏈接。harbor把消息發給目標harbor。

                harbor間的通信為單向的tcp管道。

                master服務來同步全局的名字服務。每個skynet都會知道其他節點上裝配了哪些服務,好路由過去。


            (2)組播

                TODO

            posted on 2014-01-16 11:25 Sheppard Y 閱讀(8941) 評論(0)  編輯 收藏 引用 所屬分類: 設計架構 、開源

            <2014年12月>
            30123456
            78910111213
            14151617181920
            21222324252627
            28293031123
            45678910

            導航

            統計

            留言簿(1)

            隨筆分類(77)

            隨筆檔案(58)

            me

            基友

            同行

            業界前輩

            最新隨筆

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            欧美精品福利视频一区二区三区久久久精品 | 中文字幕久久波多野结衣av| 久久综合久久伊人| 国产精品久久新婚兰兰| 蜜臀av性久久久久蜜臀aⅴ| 99精品久久精品| 久久久久国产精品嫩草影院| 久久人人爽人人爽人人爽| 精品久久香蕉国产线看观看亚洲| 7国产欧美日韩综合天堂中文久久久久| 久久夜色撩人精品国产小说| 日产精品久久久久久久| 国产精品久久久天天影视香蕉 | 久久国产成人午夜aⅴ影院 | 国产99久久久国产精品小说| 97精品国产97久久久久久免费| 伊人久久大香线蕉成人| 久久香蕉综合色一综合色88| 亚洲国产精品无码久久久不卡 | 久久精品国产免费| 亚洲香蕉网久久综合影视| 91精品国产高清久久久久久国产嫩草| 久久婷婷五月综合97色直播| 国产成人综合久久精品尤物| 99久久无色码中文字幕| 无码人妻少妇久久中文字幕蜜桃| 久久久免费观成人影院| 四虎国产精品免费久久5151| 久久精品国产亚洲AV无码偷窥| 综合久久给合久久狠狠狠97色 | 精品国产一区二区三区久久久狼| 久久久久青草线蕉综合超碰| 久久久青草青青国产亚洲免观| 一本一道久久精品综合| 久久精品国产亚洲网站| 久久99精品综合国产首页| 99久久精品国内| 日本一区精品久久久久影院| 国产69精品久久久久9999| 国内精品久久久久久久久电影网| 亚洲嫩草影院久久精品|