400-638-8808
|
微信公眾號




穩(wěn)定可靠 永不間斷

海外收發(fā) 暢通無阻

協(xié)同辦公 資源管理

超大郵件 超級功能

智能反垃圾郵件技術(shù)
易管理 免維護


在游戲開發(fā)中,我們經(jīng)常會遇到一些技術(shù)難題,而其引發(fā)的bug則會影響整個游戲的品質(zhì)。
過載保護、集群、服務器通信、并發(fā)選型等方面的問題,是中小團隊常常的技術(shù)難題,本文分享了一些專家在坐診過程中提到的解決方法,希望對大家有所幫助。
問題一:玩家登錄時拉取好友信息,但好友服務繁忙導致登錄失敗。
解決方法:
1、分離關(guān)鍵路徑上非關(guān)鍵調(diào)用,縮短事務流程,避免周邊服務異常阻塞登錄。
2、服務熔斷機制,超出處理能力快速失敗,防止雪崩。
3、按用戶隔離事務,避兔單個用戶請求阻塞影響到其他用戶。
問題二:壓測并發(fā)登錄對redis產(chǎn)生很大壓力。
解決方法:redis數(shù)據(jù)表數(shù)量多,一次事務會產(chǎn)生多個 redis請求,小表合并為大表。
Wade:服務器進程的管理一般比較簡單,有很多還是用配置文件靜態(tài)組織的。同時往往進程間通信的手段比較缺乏,沒有使用消息隊列中間件,甚至還有用 Redis 來做通信組件使用的。為了提高集群管理的自動化水平,使用 ZooKeeper 是一個比較常見的方法。
Zc:redis一般做為內(nèi)存緩存來使用,不宜將關(guān)鍵數(shù)據(jù)存放在redis中.其數(shù)據(jù)安全性并不如一般的DB。在使用過程中也需要參考性能基線,控制訪問頻率和流量。
問題三:外部服務有延遲,調(diào)用到的業(yè)務流程中產(chǎn)生卡頓。
解決方法:業(yè)務側(cè)增加緩存:同玩好友msdk+最近角色id+角色信息。
Wade:很多團隊對于過載保護不夠重視,往往只在最外層接入客戶端一側(cè)有最大連接數(shù)或者最大會話數(shù)的限制。而對于內(nèi)部的多個進程,比如訪問數(shù)據(jù)庫的進程,就沒有太多的負載保護。由于游戲是帶狀態(tài)的進程比較多,所以負載均衡往往也做的不多,基本上是按狀態(tài)所在進程去轉(zhuǎn)發(fā)處理請求。
Zc:注意緩存和降級處理。外部平臺數(shù)據(jù),盡量緩存,提高訪問體驗。當發(fā)現(xiàn)外部服務出現(xiàn)故障,或本身出現(xiàn)負載風險時,應降級服務。
Jovi:msdk midas平臺特權(quán)等api接入工作,游戲業(yè)務可以建立一個隔離層專門處理這塊需求,避兔過分侵入游戲邏輯,更容易控制。
問題四:運營和客服接口修改玩家數(shù)據(jù),會與正常游戲的數(shù)據(jù)回寫產(chǎn)生競爭。
解決方法:使用類似郵件機制去修改數(shù)據(jù)。
Zc:多線程開發(fā)中,經(jīng)常會有線程池用盡或線程死鎖導致服務質(zhì)量下降。建議將線程池根據(jù)業(yè)務需求合理分類,不同業(yè)務間有合理的負載配比,不會相互影響。非關(guān)鍵流程需要延后或者異步化處理,避免卡死關(guān)鍵流程。
同時,合理的線程模型可以有效減少線程間競爭。對確實需要競爭的資源在流程入口處統(tǒng)一有序加鎖,避免在邏輯過程中,隨意嵌套取鎖競爭。并且,給鎖加個超時時間,避免業(yè)務中斷。
Jovi:確保同一時刻只有單個數(shù)據(jù)修改點,有助于避免數(shù)據(jù)競爭。建議設計時采用CQRS方式,采用獨立的數(shù)據(jù)表和服務記錄事件,匯總到單一修改服務上執(zhí)行。
Wade:并發(fā)編程是服務器端最常見的問題,一般會用多線程或者非阻塞兩種方法之一解決。對于天然支持多線程的語言,如JAVA,很多開發(fā)者傾向多線程,好處是代碼編寫起來比較方便,但是這就要很清醒的對各種對象進行鎖的操作,或者熟練使用類似 java.util.concurrent 這種多線程工具庫。而如果使用非阻塞,好處是不會有鎖的問題,但代碼被分割到各個回調(diào)函數(shù)中,可讀性非常糟糕,所以有的團隊會使用“協(xié)程”或者 Promise 之類的工具來緩解這個問題,但這也引入了更多的復雜性。
下面詳細介紹一下游戲服務器端架構(gòu)中的調(diào)度架構(gòu),方便大家理解。
a) 單進程游戲服務器
最簡單的游戲服務器只有一個進程,是一個單點。這個進程如果退出,則整個游戲世界消失。在此進程中,由于需要處理并發(fā)的客戶端的數(shù)據(jù)包,因此產(chǎn)生了多種選擇方法:

[圖-單進程調(diào)度模型]
同步-動態(tài)多線程
每接收一個用戶會話,就建立一個線程。這個用戶會話往往就是由客戶端的TCP連接來代表,這樣每次從socket中調(diào)用讀取或?qū)懗鰯?shù)據(jù)包的時候,都可以使用阻塞模式,編碼直觀而簡單。有多少個游戲客戶端的連接,就有多少個線程。但是這個方案也有很明顯的缺點,就是服務器容易產(chǎn)生大量的線程,這對于內(nèi)存占用不好控制,同時線程切換也會造成CPU的性能損失。更重要的多線程下對同一塊數(shù)據(jù)的讀寫,需要處理鎖的問題,這可能讓代碼變的非常復雜,造成各種死鎖的BUG,影響服務器的穩(wěn)定性。
同步-多線程池
為了節(jié)約線程的建立和釋放,建立了一個線程池。每個用戶會話建立的時候,向線程池申請?zhí)幚砭程的使用。在用戶會話結(jié)束的時候,線程不退出,而是向線程池“釋放”對此線程的使用。線程池能很好的控制線程數(shù)量,可以防止用戶暴漲下對服務器造成的連接沖擊,形成一種排隊進入的機制。但是線程池本身的實現(xiàn)比較復雜,而“申請”、“釋放”線程的調(diào)用規(guī)則需要嚴格遵守,否則會出現(xiàn)線程泄露,耗盡線程池。
異步-單線程/協(xié)程
在游戲行業(yè)中,采用Linux的epoll作為網(wǎng)絡API,以期得到高性能,是一個常見的選擇。游戲服務器進程中最常見的阻塞調(diào)用就是網(wǎng)路IO,因此在采用epoll之后,整個服務器進程就可能變得完全沒有阻塞調(diào)用,這樣只需要一個線程即可。這徹底解決了多線程的鎖問題,而且也簡化了對于并發(fā)編程的難度。但是,“所有調(diào)用都不得阻塞”的約束,并不是那么容易遵守的,比如有些數(shù)據(jù)庫的API就是阻塞的;另外單進程單線程只能使用一個CPU,在現(xiàn)在多核多CPU的服務器情況下,不能充分利用CPU資源。異步編程由于是基于“回調(diào)”的方式,會導致要定義很多回調(diào)函數(shù),并且把一個流程里面的邏輯,分別寫在多個不同的回調(diào)函數(shù)里面,對于代碼閱讀非常不利。——針對這種編碼問題,協(xié)程(Coroutine)能較好的幫忙,所以現(xiàn)在比較流行使用異步+協(xié)程的組合。不管怎樣,異步-單線程模型由于性能好,無需并發(fā)思維,依然是現(xiàn)在很多團隊的首選。
異步-固定多線程
這是基于異步-單線程模型進化出來的一種模型。這種模型一般有三類線程:主線程、IO線程、邏輯線程。這些線程都在內(nèi)部以全異步的方式運行,而他們之間通過無鎖消息隊列通信。
b) 多進程游戲服務器
多進程的游戲服務器系統(tǒng),最早起源于對于性能問題需求。由于單進程架構(gòu)下,總會存在承載量的極限,越是復雜的游戲,其單進程承載量就越低,因此開發(fā)者們一定要突破進程的限制,才能支撐更復雜的游戲。
一旦走上多進程之路,開發(fā)者們還發(fā)現(xiàn)了多進程系統(tǒng)的其他一些好處:能夠利用上多核CPU能力;利用操作系統(tǒng)的工具能更仔細的監(jiān)控到運行狀態(tài)、更容易進行容災處理。多進程系統(tǒng)比較經(jīng)典的模型是“三層架構(gòu)”:
在多進程架構(gòu)下,開發(fā)者一般傾向于把每個模塊的功能,都單獨開發(fā)成一個進程,然后以使用進程間通信來協(xié)調(diào)處理完整的邏輯。這種思想是典型的“管道與過濾器”架構(gòu)模式思想——把每個進程看成是一個過濾器,用戶發(fā)來的數(shù)據(jù)包,流經(jīng)多個過濾器銜接而成的管道,最后被完整的處理完。由于使用了多進程,所以首選使用單進程單線程來構(gòu)造其中的每個進程。這樣對于游戲程序開發(fā)來說,結(jié)構(gòu)清晰簡單很多,也能獲得更高的性能。

[圖-經(jīng)典的三層模型]
盡管有很多好處,但是多進程系統(tǒng)還有一個需要特別注意的問題——數(shù)據(jù)存儲。由于要保證數(shù)據(jù)的一致性,所以存儲進程一般都難以切分成多個進程。就算對關(guān)系型數(shù)據(jù)做分庫分表處理,也是非常復雜的,對業(yè)務類型有依賴的。而且如果單個邏輯處理進程承載不了,由于其內(nèi)存中的數(shù)據(jù)難以分割和同步,開發(fā)者很難去平行的擴展某個特定業(yè)務邏輯。他們可能會選擇把業(yè)務邏輯進程做成無狀態(tài)的,但是這更加加重了存儲進程的性能壓力,因為每次業(yè)務處理都要去存儲進程處拉取或?qū)懭霐?shù)據(jù)。
除了數(shù)據(jù)的問題,多進程架構(gòu)也帶來了一系列運維和開發(fā)上的問題:首先就是整個系統(tǒng)的部署更為復雜了,因為需要對多個不同類型進程進行連接配置,造成大量的配置文件需要管理;其次是由于進程間通訊很多,所以需要定義的協(xié)議也數(shù)量龐大,在單進程下一個函數(shù)調(diào)用解決的問題,在多進程下就要定義一套請求、應答的協(xié)議,這造成整個源代碼規(guī)模的數(shù)量級的增大;最后是整個系統(tǒng)被肢解為很多個功能短小的代碼片段,如果不了解整體結(jié)構(gòu),是很難理解一個完整的業(yè)務流程是如何被處理的,這讓代碼的閱讀和交接成本巨高無比,特別是在游戲領(lǐng)域,由于業(yè)務流程變化非常快,幾經(jīng)修改后的系統(tǒng),幾乎沒有人能完全掌握其內(nèi)容。
天下數(shù)據(jù)擁有超15年游戲運營經(jīng)驗,全球50+ CN2頂級網(wǎng)絡,1300+個CDN節(jié)點資源,包括并不僅限于中國香港,美國,日本,韓國,新加坡,馬來西亞等10多個國家直接CN2高速專線接入。無條件免備案,提供智能化DDOS防護升級,負載均衡優(yōu)化,數(shù)據(jù)庫集群服務及建議,CDN節(jié)點布局優(yōu)化等一系列高品質(zhì)服務,打造適合企業(yè)穩(wěn)抓客戶布局全球的全能型游戲解決方案。詳詢天下數(shù)據(jù)客服電話400-6388-808 。
產(chǎn)品與服務
香港服務器 香港高防服務器 美國服務器 韓國服務器 新加坡服務器 日本服務器 臺灣服務器云服務器
香港云主機 美國云主機 韓國云主機 新加坡云主機 臺灣云主機 日本云主機 德國云主機 全球云主機高防專線
海外高防IP 海外無限防御 SSL證書 高防CDN套餐 全球節(jié)點定制 全球?qū)>GPLC關(guān)于我們
關(guān)于天下數(shù)據(jù) 數(shù)據(jù)招商加盟 天下數(shù)據(jù)合作伙伴 天下數(shù)據(jù)團隊建設 加入天下數(shù)據(jù) 媒體報道 榮譽資質(zhì) 付款方式關(guān)注我們
微信公眾賬號
新浪微博
天下數(shù)據(jù)手機站 關(guān)于天下數(shù)據(jù) 聯(lián)系我們 誠聘英才 付款方式 幫助中心 網(wǎng)站備案 解決方案 域名注冊 網(wǎng)站地圖
天下數(shù)據(jù)18年專注海外香港服務器、美國服務器、海外云主機、海外vps主機租用托管以及服務器解決方案-做天下最好的IDC服務商
《中華人民共和國增值電信業(yè)務經(jīng)營許可證》 ISP證:粵ICP備07026347號
朗信天下發(fā)展有限公司(控股)深圳市朗玥科技有限公司(運營)聯(lián)合版權(quán)
深圳總部:中國.深圳市南山區(qū)深圳國際創(chuàng)新谷6棟B座10層 香港總部:香港上環(huán)蘇杭街49-51號建安商業(yè)大廈7樓
7×24小時服務熱線:4006388808香港服務電話:+852 67031102
本網(wǎng)站的域名注冊業(yè)務代理北京新網(wǎng)數(shù)碼信息技術(shù)有限公司的產(chǎn)品