腾讯游戏DBA团队的发展自白
BA這個崗位跟倉管員很像,就是每天給別人發點貨,別人在你這兒放點貨,DBA工作就是把貨盡快給送出去或者讓人家盡快放進來。當然,還有一份重要的工作,就是讓倉庫里擺放的貨物盡可能整齊,這也是倉管員的本職工作,你不能拿到貨往倉庫里一通亂扔,別人來取貨,又讓別人等上半個小時。
?
圖:騰訊游戲DBA Team Leader Robin
?
內容提綱:
前輩的積累
Game Cloud Storage架構
Game Cloud Storage組成
Game Cloud Storage去哪
驅動力及方向探討
前輩的積累:三類游戲DB架構解析
圖:前輩的積累
?
圖: 騰訊互娛的三類游戲
騰訊互娛有三類PC端游戲:1. 平臺休閑游戲,比如QQGame斗地主、QQ寵物;2. 高級休閑游戲,因為游戲實時性要求增高,對用戶需要就近接入,這類游戲會進行分區處理;3. 大型多人在線游戲MMOG,這類游戲玩法比較復雜,可能包含上萬個任務,道具信息,邏輯很復雜,實時性要求更高,對應單用戶數據量也會變得更大,新的MMOG游戲或者運營時間長的MMOG單用戶數據量會達到幾百K。手游這幾年本身游戲內容不斷的豐富,演進中的游戲分類基本也可以參考原先端游。
圖:PLAT/QQGame DB分布
對于平臺休閑/QQ游戲的DB,數據集中一個城市存放。因為游戲玩法相對最簡單,所以,玩家自身的屬性較少,可能就是積分、榮譽、裝扮,少量道具的變化,對應數據量也比較小,比較適合集中存放,不同地域的gamesvr到專線也不會有太大壓力。
此類DB特點:
-
DB數據集中,基本分布在同城IDC;
-
單用戶數據結構簡單,數據量少(<1K);
-
用戶量巨大,通常注冊用戶過億,后臺通過qq號hash或者uin末尾2-3位數字做分布式數據切片處理;
-
單DBServer支持訪問人數大于10萬。
圖:ACG/飛車 DB分布
相對MMOG,ACG/飛車的游戲內容比較簡單,以玩家對局為主,但單用戶的數量會比PLAT / QQGame要大一點,需要大區方式運營,產品策劃對于用戶聚合有更多訴求,大區增加相對少,反而單個大區承載人數的上限,會因為時間推移,逐步通過技術升級不斷提升。
DB特點:
-
介于PLAT,MMOG之間,單大區支持人數有10萬。
圖:MMOG/ 三國DB分布
MMOG/ 三國游戲邏輯復雜,用戶屬性多,玩家升級、打怪、做任務、多人組隊作戰PK為主。本身一個大區,因為內容過多,復雜的經濟系統平衡等,同時承載人數有幾萬的上限,需要通過不斷增加大區,擴張在線人數。實時性要求更高,適合把整個游戲的后臺物理設施跟用戶作就近接入,這樣用戶體驗會更好一些。
DB特點:
-
DB數據分布廣,分布在多個IDC;
-
單用戶數據結構簡單,數據量少(50K-幾百K);
-
DBServer物理及邏輯擴展頻繁,單個區支持同時游戲人數在2-3萬。
圖:DB架構簡化
經過總結,發現其實架構是蠻簡單的,我們的MySQL就很簡單,一個Master,一個Slave,一個LogDB,把三種游戲精練一下,其實就是一個很簡單的架構,如上圖。
我們總結了一個經驗,因為單用戶數據量比較小的話,DB部署的適合集中存在一個城市;如果像一個用戶的玩家數據達到幾百K的時候,還是適合整體單區架構包括數據庫做就近接入、Set化。
圖:DB架構精粹
-
數據部署策略:集中與Set分布,數據集中適合邏輯簡單,用戶屬性較少的游戲;IDC Set分布,適合邏輯復雜,用戶屬性多游戲.
-
數據切割策略:平行(QQ號或其它用戶ID)及垂直(不同模塊屬性數據,例如QQGame的道具與裝扮信息的切分)
-
成本與質量策略:分級投入,核心狀態與日志流水硬件分離,讓讀寫最頻繁的狀態類信息保持一個較小的規模,為核心狀態類數據增加熱備投入。流水日志現在因為近幾年大數據很時髦,也有傳輸到hadoop做分析,也相當于有備份了。
-
回寫策略:前端cache定時合并回寫,本身Mysql設置innodb_flush_log_at_trx_commit=0,提升2-3倍性能。
-
簡化策略:對于MMOG將用戶屬性中數據量較大的任務,道具,倉庫信息以二進制方式封裝到Blob中。盡可能將DB問題簡化為或IO或內存或CPU資源不足的問題。
-
SNS游戲沒有列出來,是因為現在所有游戲幾乎都包含了SNS元素,但當社交變為游戲的重點時,因為熱點不在集中,首要策略是All In Memory,比如前些年特別流行的QQ農場業務。
Game Cloud Storage 架構
圖:Game Cloud Storage架構
Game Cloud Storage主要解決硬件故障處理時間長,版本停機時間長,以及空閑率高這三個問題。mysql前增加了proxy一層做高可用;推出定制的tmysql,秒級在線加字段;以及將多實例管理變得更加方便,便于縮擴容。
自動切換
圖:Auto-Switch
Auto-Switch首要的考慮是避免誤切換。不切換影響最多回到從前,但誤切換可能導致更加復雜的問題,比如切換到一個落后了幾天數據的Slave,意味著要整體停機,數據亂了,耗費N個小時來做用戶數據回檔工作,新的用戶數據完全丟失。
MySQL Proxy定制擴展
-
refresh_backends,在proxy管理端口擴展了一個核心的指令refresh backend,通過外圍控制,外圍檢測到master故障,一個指令將proxy指向slave,引導后續gamesvr來的正常訪問,通過增加proxy整體訪問切割,也避免一致性問題;
-
Refresh_user,做user@ip白名單的控制,Proxy本身當它作為MySQL代理的時候,MySQL看到的ip已經都是proxy,增強這一點來延續對于MySQL對來源IP的控制。
-
Show_processlist,查看來源連接,在MySQL里看到的都是來自于proxy的連接,這個時候也不方便去定位一些來源鏈接的問題,所以proxy需要看到能更直接地來自于gameserver等等前端詳細信息。
-
Refresh_connlog,打開記錄連接log,保證整個所有DB的請求,可以追溯來源。
監控邏輯
多點監控
高可用切換主要依賴外圍的集中監控,我們分了幾個大的IDC,比如成都、深圳和上海等,我們會在大的區域本地進行監控,比如成都會有本地的點去對成都所有DB定時監測,深圳也會監測,并會對比這兩者,如果兩者有一者存活的話,那就不做處理,如果兩者都有問題的話,就會考慮開始把它進行切換,這是多點監控。
SQL探測,SSH登陸
先通過replace sql探測DB端口,成功則認為ok,否則通過ssh登陸,及touch文件探測。為什么要以SHH作為條件?因為MySQL負載高的時候,SQL探測遇到Hang住異常,希望ssh進一步去探測物理機器存活,如果ssh登陸不了或ssh后touch遇到只讀,我們基本斷定一臺機器故障了,這個時候,會推送到下一步第二輪探測隊列,以便整機切換。
DoubleCheck
前述第一輪探測,檢驗完成后,進行Double Check探測,確認問題后,同時檢查一下Slave這些跟進的狀態是不是對的,最近的數據Check Sum校驗是不是一致的,是否有主備Time delay。
最后,滿足切換的前置條件包括以下幾方面:
show slave status, 獲取binlog獲取及本地relay執行對比;
Checksum(7天內)不一致塊數量,小于5個塊可進行切換;
Slave落后Master時間, 小于10秒為可進行切換;
Master已故障時間,小于10分鐘可進行切換;
壓縮
圖:壓縮
關于Blob我們遇到的一個問題是,當時比較火的《地下城與勇士》,上線剛半年單機數據量達到200多G。當時跑的硬件只是只有8G內存,6塊SAS磁盤一臺機器,一個周末因為夜間備份時間過長,到了白天還沒結束,業務連續出了2個突發。后來,我們跟韓國的開發商商定了壓縮這個投入最小的方案,通過一次停機,整體數據做一次壓縮,整個數據庫數據從200多G變成了4G。
同時,后續數據修改,從數據庫拿到數據后進行gameserver進行解壓,在gameserver寫入數據庫前就進行壓縮。根據在Slave上對OSS金錢統計相關數據進行的經營統計分析,發現原來要執行400分鐘的,基本上降低到5分鐘。很簡單的壓縮還是蠻有用的,控制核心數據量,對后續這個游戲長續運營產生了極大的幫助,這個游戲早期被外界叫做掉線城與虛弱勇士,我想我們做的很簡單的事情,對于幫助游戲丟掉這個惡名還是有一點幫助的。
圖:壓縮演進歷程
壓縮演進歷程:
2008年,遇到一款MMOG游戲,單一用戶量很大,當時想到最簡單的辦法就是壓縮。開發方,在select時候,用mysql自身的uncompress做解壓,update直接sql里邊用mysql函數compress寫回,用MySQL的技術就搞定了。
2011年,逐步會有一些內部的ORM DB公共組件可以做一些透明開關,通過中間件層去壓縮數據。
2013年,前面幾種辦法都不是DBA能完全cover的,總需要開發更新中間件,或者改寫sql,或者更新gameserver邏輯,我們想了一招,就是把Mysql內完全解決這個問題,完全對開發透明,只要給字段通過alter增加Compress的屬性,在MySQL底層直接就把大字段壓縮給做了。這個效率,我們測試中發現遠好于本身innodb page壓縮。
監控
-
2007年前,監控是比較零散的。
-
2007年剛入職,接到的第一個稍大的任務就是給DB寫監控,我們都把監控放在數據庫機器本地,還有一些Hang判斷,ErrorLog檢測,還有status我們收集了232個。
-
2009年,因為有時候某個指標異常的時候,難以得到問題相關因素現場,所以我們針對slowquery量及io利用率超過一定閥值去做了一些現場保留工作,比如show processlist,ps aux,top等,并保存在監控日志里邊。同時,也做了checksum的辦法,OS層指標增加一些我們急需的但公司網管系統并未涉及的,比如每個分區的ioutil等。
-
2012年,為了配合做GCS高可用,做一些時間同步的檢測;為了能更方便地去對比一些DB的性能,聚合性能指標在一起,做了特別方便的性能對比工具。
Game Cloud Storage去哪
圖:Game Cloud Storage去哪
思考GCS去哪,本身也是在想源碼定制這條路該往哪里走?如果大家對開源軟件比較有興趣的話,可以參考我們走過的路,可以先嘗試簡單功能的優化,然后考慮擴展至性,再考慮性能,因為性能優化的挑戰,涉及到mysql底層更復雜的鎖調優等機制優化,我一直覺得還是蠻大的。最近一兩年,在線加字段這個痛點解決折后,我們一直希望能MySQL在保持mysql協議基本不變的前提下,能像nosql類似MongoDB擴展性那么好,在這方面做了一些探索。
我們選用了Spider,一個分布式的MySQL底層存儲引擎來解決這個問題,前一兩年開始研究這個Spider,到現在已有超過10個業務上用了起來。Spider官方,在最近一兩年也不斷完善,合并到MariaDB 10的正式版本里面。大家如果對數據庫分布式有需求,同時不希望開發太多修改,可以考慮MariaDB 10的版本。
圖:運維的驅動力
最近業界有很多運維發展方向的討論,我自身也在思考運維的核心驅動力到底是什么。如果我去回顧過去的一些歷程,我自己考慮運維核心的驅動力還是最簡單兩個字——問題。可能來自業務發展的快速增大數據量,請求并發增大,或者開發使用整個存儲的容易程度,或者平時運維的一些問題,我們不希望自己那么多通宵處理故障,那么多步驟那么辛苦縮擴容。不管在哪家公司,只要我還能夠不斷解決問題,可能這個公司我還能呆得下去;如果沒有問題需要解決,或者是天天時間都花在其他地方了,可能也就沒什么意思了。
圖:內部平臺產品方向
我們做這些內部平臺,按目前的人力投入,最重要的還是聚焦支撐內部精品大業務的發展。但站在內外部技術平臺競爭加劇的角度,每天都能看到各種各樣渠道吹牛的信息(就像我今天這樣),都說自己很厲害,很強,我們的下一步該怎么走,怎么證明自己的價值,獲得應有的認可,這是個很關鍵的問題。
聽了很多業界大拿的建議,比如葉金榮同學,平靜的思考之后,我們后續計劃或者是策略大概是:首要的,仍然會站在“巨人的肩膀上”,更好的使用及支持整個社區開放協議存儲方案,通過更為深入研究積累,能提供基本閉環的服務支撐能力;第二步,關于怎么證明團隊價值,從前幾年的“定制”方向轉變到“回到社區”方向,在那個更加廣袤的空間去追求些許的認可。
更新這個ppt之前,翻出來多年前內部分享的一頁ppt,“關于DB的美好想象”,其中第一點因為牽扯業務過于多樣化邏輯數據設計,還是沒做到,第二點做到一點點。
轉載于:https://www.cnblogs.com/zping/p/9002659.html
總結
以上是生活随笔為你收集整理的腾讯游戏DBA团队的发展自白的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: .net mvc ef 视图未定义主键问
- 下一篇: 实验五 类和对象-3 zxt