<button id="hu96j"><acronym id="hu96j"></acronym></button><dd id="hu96j"><pre id="hu96j"></pre></dd>
        <video id="hu96j"><font id="hu96j"><th id="hu96j"></th></font></video>
          <nav id="hu96j"></nav>
        <tbody id="hu96j"><center id="hu96j"><video id="hu96j"></video></center></tbody>

      1. <dd id="hu96j"><track id="hu96j"></track></dd>

        <dd id="hu96j"></dd>
        <rp id="hu96j"><acronym id="hu96j"></acronym></rp>
      2. <button id="hu96j"></button>

        • 保存到桌面加入收藏設為首頁
        服務器技術

        社交游戲之可行雙機熱備方案 預防單點故障

        時間:2013-07-03 11:44:52   作者:idc機房   來源:IT專家網   閱讀:17772   評論:0
        內容摘要:我們靜下心研究解決這些服務器作為單點運行的問題,為此研發出解決各個游戲引擎組建服務的主備提供服務的通用性組建,也即其他游戲引擎組建通過引入hot-standby組建,可以解決單點故障的問題.
          某一天深夜,單盤配置的服務器出現硬盤損壞,導致該服務器上所提供的服務停止,于是有了開發雙機熱備服務的想法,經過長時間(半年)的多人的努力,這個東西慢慢就出來了?;诟鞣N原因,這里不能提供相關源代碼,僅僅提供設計思想C基本實現思路和實現過程遇到的問題和挑戰,順帶記錄下這半年努力的成果,若有描述不夠詳細或清楚的地方,敬請見諒!
         
          1. 穩定性思考
         
          廢話不多說,本文所說的服務器特指使用C /C++ 實現的中間件角色的應用服務器,比如DB Proxy(Cache) Server,常規MMORPG架構中的中心服務器,在其整體應用中都是以單點的形式存在,而且所起的作用又及其重要,如何應對各種程序問題或者不可控因素引起的Crash,而把其Crash所造成的損失減少到最低,這里介紹一個已實現并且可行的雙機熱備(hot-standby)解決方案。
         
          名詞解釋:
         
          HS: 當前雙機熱備技術架構簡稱
         
          Master: 主服務器,即當前online服務器
         
          Slave: 從服務器,即備份服務器,offline服務器
         
          服務器: Master或者Slave
         
          2. 雙機互備工作方式
         
          HS工作在【主-從】模式下,即同一時間只有一臺服務器提供服務,默認情況下Slave服務器不處理外部請求命令,只處理由Master端發來的同步請求。
         
          這種情況下,服務器提供統一的接口給LVS,如果LVS檢測到Master無響應或停止工作,則發命令使Slave變成服務器(online)模式,同時將客戶端請求都轉到Slave,此時Slave主機也就升級成為Master,工作方式如下圖所示:
         
         社交游戲之可行雙機熱備方案_預防單點故障
         
          3. 軟件架構
         
          HS是被設計成通用性模塊,理論上可以供所有應用服務器接入使用,如下圖所示:
         
         社交游戲之可行雙機熱備方案_預防單點故障 
         
          由于HS模塊自身并沒有網絡傳輸功能,在集成中還需要將應用服務器的網絡I/O接口接入到HS模塊(常規情況下,應用服務器的網絡I/O模塊都會提供單獨接口?)。
         
          整體架構如Figure.3,HS自己運行一個線程,對所有異步傳遞到HS模塊的數據,先使用queue進行排隊緩存,再在本線程內一有越其傳輸到配置的Slave端,同時這部分數據也會寫入模塊的第三方存儲(HS目前只實現了Memory存儲)。
         
          Slave在接收到Master傳輸的data后,更新應用服務器相關內存(根據Master發送的KEY可以確定具體的內存類型),同時也會將接收到的數據寫入自身的數據緩沖隊列和第三方存儲。
         
          Master和Slave只要編寫很少代碼(發送時HOOK,接收時更新)就可以實現一個完備的hot-standby server。
         
          社交游戲之可行雙機熱備方案_預防單點故障
         
          這里就有個疑問了,為什么Slave也需要維護一個queue和第三方存儲呢?這是因為Slave可能會在未來的某一天會變成Master,需要同步數據給未來的一個Slave。下圖流程圖說明了服務器啟動的過程。
         
          社交游戲之可行雙機熱備方案_預防單點故障
         
          4. 模塊化
         
          HS可以單獨編譯成動態庫形式(.so)使用。
         
          具體實現中使用boost的一些庫,主要有io_service,thread,bind,shared_ptr等。
         
          不過在編譯時可以選擇將boost庫靜態編譯,實際使用上就不用單獨進行依賴了。
         
          需要說明的是,為了更好的支持HS的運行,遠程過程調用模塊被開發出來,這里就不詳述了。
         
          5. 網絡傳輸如何處理突如其來的大數據量
         
          在某種極端情況下,當Master啟動了很久之后,Slave才姍姍來遲,Master可能積累了大量的數據(超過4G),這個時候如果Master對Slave進行無限制的傳輸數據,會占用大量的網卡資源(不過一般雙網卡,不影響外網服務),最重要的會占用大量網絡線程資源(HS和應用服務器公用網絡線程)。
         
         渴導什饈災蟹⑾鄭由于4G的小塊數據大小不一,傳輸耗時超過1分鐘。為了避免對應用服務器的網絡線程擁塞,加入了傳輸數據的流量控制,在每個間隔時間內只傳輸指定配置的數據量,測試證明,這個方法解決了所有相關問題。
         
          第三方存儲有什么用?
         
          Slave端斷開后或者在Master啟動一段時間后再連上來時,用于存儲歷史備份數據。就是說Slave 在斷開很長時間之后再連上來,期間所有的歷史數據y是在第三方存儲中。連上后,首先需要同步的第三方存儲的數據,完成后再對queue中的數據進行實時同步。
         
          6. Socket的幽靈屬性keepalive
         
          為了檢測網線斷開或者不可知的網絡異常,HS需要一套能夠檢測網絡真斷開,還是偽斷開(比如網絡短時間內的不通),首先想到了利用TCP/IP協議自身的屬性,即KEEPALIVE,經使用測試發現,這個不是很好的檢查機制,至少不是我們需要的。因為KEEPALIVE依t系統的三個屬性,如下所示:
         
          系統設置
         
          # cat /proc/sys/net/ipv4/tcp_keepalive_time
         
          7200
         
          # cat /proc/sys/net/ipv4/tcp_keepalive_intvl
         
          75
         
          # cat /proc/sys/net/ipv4/tcp_keepalive_probes
         
          9
         
          簡單說明下,這個三個屬性表示TCP/IP協議層會在7200秒沒有收到客戶端消息的情況下,發送10(9+1)個報文段,每兩個間隔75秒,若客戶端對這些信息都沒有響應,則終止該連接。
         
          不使用這個屬性的兩個理由,一是這些信息屬于系統屬性級別的改動,二是實際測試中發現很不穩定。
         
          以下為設置keepalive的代碼:
         
          int optval = 1;
         
          socketlen_t optlen = sizeof(optval);
         
          setsockopt(socket, SOL_SOCKET, SO_KEEPALIVE, &optval, optlen);
         
          更有效的心跳方案:
         
          就是自己實現,方案比較土,簡單描述下:
         
          服務器維護兩個變量A和B,一個定時器,客戶端每來一個請求包,A變量自增1,同時在定時器到點時,檢測A和B是否相同,如果不同表明客戶端是活動的,同時將A同步到B,開始下一輪定時器。若一個連接有N次的定時器到點是都未活動,則判定客戶端斷開,關閉該連接。
         
          7. OVER
         
          【編加注】
         
          專注于社交游戲的研發與運營,逐漸對社交游戲產品的業務越來越熟悉,不斷地總結與分析,加快社交游戲產品的研發速度,我們技術團隊做很多研究與嘗試,為此我們開發出來產品:
         
          1) 數據中間件:解決大用戶并發與大數據量的問題,不需要游戲研發工程師關心數據的存取等;
         
          2) 任務服務器:解決游戲產品眾多活動或獎勵活動的舉辦,以及游戲自身任務的配置與管理;
         
          3) 統計服務器:我們玩家的操作日志數據量太大,無法全部存儲到服務器上,為此有選擇地存儲相關玩家的行為日志數據,并且完成數據分析的工作;
         
          4) 好友列表服務器:社交游戲產品主要是接入眾多的社交網站平臺,為此要實現一套通用的好友列表服務器;
         
          5) …..等其他游戲引擎組建
         
          隨著推出上述相關通用性游戲引擎的組建,我們也逐漸贏得更多時間與精力可以做更有意義的事情,比如我們可以靜下心研究解決這些服務器作為-點運行的問題,為此研發出解決各個游戲引擎組建服務的主備提供服務的通用性組建,也即其他游戲引擎組建通過引入hot-standby組建,可以解決單點故障的問題。這個通用性組建,也可以為非社交游戲行業的服務器后臺程序的熱備模式,提供一定的技術參考價值。感謝@ZEROV17的投稿支持,也歡迎各位技術朋友站內留言或者新浪微博直接交流,同時也非常感謝零度視角F為此項目所作的貢獻!
         


        IDCsped 提供最新的IT互聯網資訊,本著分享、傳播的宗旨,我們希望能幫助更多人了解需要的信息!

        部分文章轉載自互聯網、部分是IDCsped原創文章,如果轉載,請注明出處:www.idcsped.com !
        微信號:13430280788  歡迎加微信交流!

        標簽:社交游戲服務器托管  雙機熱備方案  游戲服務器托管  
        相關評論

        銷售電話:13430280788

        Copyright © 2012-2017 | www.idcsped.com 版權所有

          粵公網安備 44010502001126號  粵ICP備12006439號-1
        Powered by OTCMS V3.61
        日韩欧美永久中文字幕视频
          <button id="hu96j"><acronym id="hu96j"></acronym></button><dd id="hu96j"><pre id="hu96j"></pre></dd>
            <video id="hu96j"><font id="hu96j"><th id="hu96j"></th></font></video>
              <nav id="hu96j"></nav>
            <tbody id="hu96j"><center id="hu96j"><video id="hu96j"></video></center></tbody>

          1. <dd id="hu96j"><track id="hu96j"></track></dd>

            <dd id="hu96j"></dd>
            <rp id="hu96j"><acronym id="hu96j"></acronym></rp>
          2. <button id="hu96j"></button>