BA這個(gè)崗位跟倉(cāng)管員很像，就是每天給別人發(fā)點(diǎn)貨，別人在你這兒放點(diǎn)貨，DBA工作就是把貨盡快給送出去或者讓人家盡快放進(jìn)來(lái)。當(dāng)然，還有一份重要的工作，就是讓倉(cāng)庫(kù)里擺放的貨物盡可能整齊，這也是倉(cāng)管員的本職工作，你不能拿到貨往倉(cāng)庫(kù)里一通亂扔，別人來(lái)取貨，又讓別人等上半個(gè)小時(shí)。

?

圖：騰訊游戲DBA Team Leader Robin

?

內(nèi)容提綱：

前輩的積累

Game Cloud Storage架構(gòu)

Game Cloud Storage組成

Game Cloud Storage去哪

驅(qū)動(dòng)力及方向探討

前輩的積累：三類游戲DB架構(gòu)解析

圖：前輩的積累

?

圖： 騰訊互娛的三類游戲

騰訊互娛有三類PC端游戲：1. 平臺(tái)休閑游戲，比如QQGame斗地主、QQ寵物；2. 高級(jí)休閑游戲，因?yàn)橛螒驅(qū)崟r(shí)性要求增高，對(duì)用戶需要就近接入，這類游戲會(huì)進(jìn)行分區(qū)處理；3. 大型多人在線游戲MMOG，這類游戲玩法比較復(fù)雜，可能包含上萬(wàn)個(gè)任務(wù)，道具信息，邏輯很復(fù)雜，實(shí)時(shí)性要求更高，對(duì)應(yīng)單用戶數(shù)據(jù)量也會(huì)變得更大，新的MMOG游戲或者運(yùn)營(yíng)時(shí)間長(zhǎng)的MMOG單用戶數(shù)據(jù)量會(huì)達(dá)到幾百K。手游這幾年本身游戲內(nèi)容不斷的豐富，演進(jìn)中的游戲分類基本也可以參考原先端游。

圖：PLAT／QQGame DB分布

對(duì)于平臺(tái)休閑／QQ游戲的DB，數(shù)據(jù)集中一個(gè)城市存放。因?yàn)橛螒蛲娣ㄏ鄬?duì)最簡(jiǎn)單，所以，玩家自身的屬性較少，可能就是積分、榮譽(yù)、裝扮，少量道具的變化，對(duì)應(yīng)數(shù)據(jù)量也比較小，比較適合集中存放，不同地域的gamesvr到專線也不會(huì)有太大壓力。

此類DB特點(diǎn)：

• DB數(shù)據(jù)集中，基本分布在同城IDC；

• 單用戶數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單，數(shù)據(jù)量少(<1K)；

• 用戶量巨大，通常注冊(cè)用戶過(guò)億，后臺(tái)通過(guò)qq號(hào)hash或者uin末尾2-3位數(shù)字做分布式數(shù)據(jù)切片處理；

• 單DBServer支持訪問(wèn)人數(shù)大于10萬(wàn)。

圖：ACG/飛車 DB分布

相對(duì)MMOG，ACG／飛車的游戲內(nèi)容比較簡(jiǎn)單，以玩家對(duì)局為主，但單用戶的數(shù)量會(huì)比PLAT / QQGame要大一點(diǎn)，需要大區(qū)方式運(yùn)營(yíng)，產(chǎn)品策劃對(duì)于用戶聚合有更多訴求，大區(qū)增加相對(duì)少，反而單個(gè)大區(qū)承載人數(shù)的上限，會(huì)因?yàn)闀r(shí)間推移，逐步通過(guò)技術(shù)升級(jí)不斷提升。

DB特點(diǎn)：

• 介于PLAT，MMOG之間，單大區(qū)支持人數(shù)有10萬(wàn)。

圖：MMOG/ 三國(guó)DB分布

MMOG/ 三國(guó)游戲邏輯復(fù)雜，用戶屬性多，玩家升級(jí)、打怪、做任務(wù)、多人組隊(duì)作戰(zhàn)PK為主。本身一個(gè)大區(qū)，因?yàn)閮?nèi)容過(guò)多，復(fù)雜的經(jīng)濟(jì)系統(tǒng)平衡等，同時(shí)承載人數(shù)有幾萬(wàn)的上限，需要通過(guò)不斷增加大區(qū)，擴(kuò)張?jiān)诰€人數(shù)。實(shí)時(shí)性要求更高，適合把整個(gè)游戲的后臺(tái)物理設(shè)施跟用戶作就近接入，這樣用戶體驗(yàn)會(huì)更好一些。

DB特點(diǎn)：

• DB數(shù)據(jù)分布廣，分布在多個(gè)IDC；

• 單用戶數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單，數(shù)據(jù)量少(50K-幾百K)；

• DBServer物理及邏輯擴(kuò)展頻繁，單個(gè)區(qū)支持同時(shí)游戲人數(shù)在2-3萬(wàn)。

圖：DB架構(gòu)簡(jiǎn)化

經(jīng)過(guò)總結(jié)，發(fā)現(xiàn)其實(shí)架構(gòu)是蠻簡(jiǎn)單的，我們的MySQL就很簡(jiǎn)單，一個(gè)Master，一個(gè)Slave，一個(gè)LogDB，把三種游戲精練一下，其實(shí)就是一個(gè)很簡(jiǎn)單的架構(gòu)，如上圖。

我們總結(jié)了一個(gè)經(jīng)驗(yàn)，因?yàn)閱斡脩魯?shù)據(jù)量比較小的話，DB部署的適合集中存在一個(gè)城市；如果像一個(gè)用戶的玩家數(shù)據(jù)達(dá)到幾百K的時(shí)候，還是適合整體單區(qū)架構(gòu)包括數(shù)據(jù)庫(kù)做就近接入、Set化。

圖：DB架構(gòu)精粹

• 數(shù)據(jù)部署策略：集中與Set分布，數(shù)據(jù)集中適合邏輯簡(jiǎn)單，用戶屬性較少的游戲；IDC Set分布，適合邏輯復(fù)雜，用戶屬性多游戲.

• 數(shù)據(jù)切割策略：平行(QQ號(hào)或其它用戶ID)及垂直（不同模塊屬性數(shù)據(jù)，例如QQGame的道具與裝扮信息的切分）

• 成本與質(zhì)量策略：分級(jí)投入，核心狀態(tài)與日志流水硬件分離，讓讀寫最頻繁的狀態(tài)類信息保持一個(gè)較小的規(guī)模，為核心狀態(tài)類數(shù)據(jù)增加熱備投入。流水日志現(xiàn)在因?yàn)榻鼛啄甏髷?shù)據(jù)很時(shí)髦，也有傳輸?shù)絟adoop做分析，也相當(dāng)于有備份了。

• 回寫策略：前端cache定時(shí)合并回寫，本身Mysql設(shè)置innodb_flush_log_at_trx_commit=0，提升2-3倍性能。

• 簡(jiǎn)化策略：對(duì)于MMOG將用戶屬性中數(shù)據(jù)量較大的任務(wù)，道具，倉(cāng)庫(kù)信息以二進(jìn)制方式封裝到Blob中。盡可能將DB問(wèn)題簡(jiǎn)化為或IO或內(nèi)存或CPU資源不足的問(wèn)題。

• SNS游戲沒(méi)有列出來(lái)，是因?yàn)楝F(xiàn)在所有游戲幾乎都包含了SNS元素，但當(dāng)社交變?yōu)橛螒虻闹攸c(diǎn)時(shí)，因?yàn)闊狳c(diǎn)不在集中，首要策略是All In Memory，比如前些年特別流行的QQ農(nóng)場(chǎng)業(yè)務(wù)。

Game Cloud Storage 架構(gòu)

圖：Game Cloud Storage架構(gòu)

Game Cloud Storage主要解決硬件故障處理時(shí)間長(zhǎng)，版本停機(jī)時(shí)間長(zhǎng)，以及空閑率高這三個(gè)問(wèn)題。mysql前增加了proxy一層做高可用；推出定制的tmysql，秒級(jí)在線加字段；以及將多實(shí)例管理變得更加方便，便于縮擴(kuò)容。

自動(dòng)切換

圖：Auto-Switch

Auto-Switch首要的考慮是避免誤切換。不切換影響最多回到從前，但誤切換可能導(dǎo)致更加復(fù)雜的問(wèn)題，比如切換到一個(gè)落后了幾天數(shù)據(jù)的Slave，意味著要整體停機(jī)，數(shù)據(jù)亂了，耗費(fèi)N個(gè)小時(shí)來(lái)做用戶數(shù)據(jù)回檔工作，新的用戶數(shù)據(jù)完全丟失。

MySQL Proxy定制擴(kuò)展

• refresh_backends，在proxy管理端口擴(kuò)展了一個(gè)核心的指令refresh backend，通過(guò)外圍控制，外圍檢測(cè)到master故障，一個(gè)指令將proxy指向slave，引導(dǎo)后續(xù)gamesvr來(lái)的正常訪問(wèn)，通過(guò)增加proxy整體訪問(wèn)切割，也避免一致性問(wèn)題；

• Refresh_user，做user@ip白名單的控制，Proxy本身當(dāng)它作為MySQL代理的時(shí)候，MySQL看到的ip已經(jīng)都是proxy，增強(qiáng)這一點(diǎn)來(lái)延續(xù)對(duì)于MySQL對(duì)來(lái)源IP的控制。

• Show_processlist，查看來(lái)源連接，在MySQL里看到的都是來(lái)自于proxy的連接，這個(gè)時(shí)候也不方便去定位一些來(lái)源鏈接的問(wèn)題，所以proxy需要看到能更直接地來(lái)自于gameserver等等前端詳細(xì)信息。

• Refresh_connlog，打開(kāi)記錄連接log，保證整個(gè)所有DB的請(qǐng)求，可以追溯來(lái)源。

監(jiān)控邏輯

多點(diǎn)監(jiān)控

高可用切換主要依賴外圍的集中監(jiān)控，我們分了幾個(gè)大的IDC，比如成都、深圳和上海等，我們會(huì)在大的區(qū)域本地進(jìn)行監(jiān)控，比如成都會(huì)有本地的點(diǎn)去對(duì)成都所有DB定時(shí)監(jiān)測(cè)，深圳也會(huì)監(jiān)測(cè)，并會(huì)對(duì)比這兩者，如果兩者有一者存活的話，那就不做處理，如果兩者都有問(wèn)題的話，就會(huì)考慮開(kāi)始把它進(jìn)行切換，這是多點(diǎn)監(jiān)控。

SQL探測(cè)，SSH登陸

先通過(guò)replace sql探測(cè)DB端口，成功則認(rèn)為ok，否則通過(guò)ssh登陸，及touch文件探測(cè)。為什么要以SHH作為條件？因?yàn)镸ySQL負(fù)載高的時(shí)候，SQL探測(cè)遇到Hang住異常，希望ssh進(jìn)一步去探測(cè)物理機(jī)器存活，如果ssh登陸不了或ssh后touch遇到只讀，我們基本斷定一臺(tái)機(jī)器故障了，這個(gè)時(shí)候，會(huì)推送到下一步第二輪探測(cè)隊(duì)列，以便整機(jī)切換。

DoubleCheck

前述第一輪探測(cè)，檢驗(yàn)完成后，進(jìn)行Double Check探測(cè)，確認(rèn)問(wèn)題后，同時(shí)檢查一下Slave這些跟進(jìn)的狀態(tài)是不是對(duì)的，最近的數(shù)據(jù)Check Sum校驗(yàn)是不是一致的，是否有主備Time delay。

最后，滿足切換的前置條件包括以下幾方面：

show slave status, 獲取binlog獲取及本地relay執(zhí)行對(duì)比；

Checksum(7天內(nèi))不一致塊數(shù)量，小于5個(gè)塊可進(jìn)行切換；

Slave落后Master時(shí)間, 小于10秒為可進(jìn)行切換；

Master已故障時(shí)間，小于10分鐘可進(jìn)行切換；

壓縮

圖：壓縮

關(guān)于Blob我們遇到的一個(gè)問(wèn)題是，當(dāng)時(shí)比較火的《地下城與勇士》，上線剛半年單機(jī)數(shù)據(jù)量達(dá)到200多G。當(dāng)時(shí)跑的硬件只是只有8G內(nèi)存，6塊SAS磁盤一臺(tái)機(jī)器，一個(gè)周末因?yàn)橐归g備份時(shí)間過(guò)長(zhǎng)，到了白天還沒(méi)結(jié)束，業(yè)務(wù)連續(xù)出了2個(gè)突發(fā)。后來(lái)，我們跟韓國(guó)的開(kāi)發(fā)商商定了壓縮這個(gè)投入最小的方案，通過(guò)一次停機(jī)，整體數(shù)據(jù)做一次壓縮，整個(gè)數(shù)據(jù)庫(kù)數(shù)據(jù)從200多G變成了4G。

同時(shí)，后續(xù)數(shù)據(jù)修改，從數(shù)據(jù)庫(kù)拿到數(shù)據(jù)后進(jìn)行g(shù)ameserver進(jìn)行解壓，在gameserver寫入數(shù)據(jù)庫(kù)前就進(jìn)行壓縮。根據(jù)在Slave上對(duì)OSS金錢統(tǒng)計(jì)相關(guān)數(shù)據(jù)進(jìn)行的經(jīng)營(yíng)統(tǒng)計(jì)分析，發(fā)現(xiàn)原來(lái)要執(zhí)行400分鐘的，基本上降低到5分鐘。很簡(jiǎn)單的壓縮還是蠻有用的，控制核心數(shù)據(jù)量，對(duì)后續(xù)這個(gè)游戲長(zhǎng)續(xù)運(yùn)營(yíng)產(chǎn)生了極大的幫助，這個(gè)游戲早期被外界叫做掉線城與虛弱勇士，我想我們做的很簡(jiǎn)單的事情，對(duì)于幫助游戲丟掉這個(gè)惡名還是有一點(diǎn)幫助的。

圖：壓縮演進(jìn)歷程

壓縮演進(jìn)歷程：

2008年，遇到一款MMOG游戲，單一用戶量很大，當(dāng)時(shí)想到最簡(jiǎn)單的辦法就是壓縮。開(kāi)發(fā)方，在select時(shí)候，用mysql自身的uncompress做解壓，update直接sql里邊用mysql函數(shù)compress寫回，用MySQL的技術(shù)就搞定了。

2011年，逐步會(huì)有一些內(nèi)部的ORM DB公共組件可以做一些透明開(kāi)關(guān)，通過(guò)中間件層去壓縮數(shù)據(jù)。

2013年，前面幾種辦法都不是DBA能完全cover的，總需要開(kāi)發(fā)更新中間件，或者改寫sql，或者更新gameserver邏輯，我們想了一招，就是把Mysql內(nèi)完全解決這個(gè)問(wèn)題，完全對(duì)開(kāi)發(fā)透明，只要給字段通過(guò)alter增加Compress的屬性，在MySQL底層直接就把大字段壓縮給做了。這個(gè)效率，我們測(cè)試中發(fā)現(xiàn)遠(yuǎn)好于本身innodb page壓縮。

監(jiān)控

• 2007年前，監(jiān)控是比較零散的。

• 2007年剛?cè)肼?/span>，接到的第一個(gè)稍大的任務(wù)就是給DB寫監(jiān)控，我們都把監(jiān)控放在數(shù)據(jù)庫(kù)機(jī)器本地，還有一些Hang判斷，ErrorLog檢測(cè)，還有status我們收集了232個(gè)。

• 2009年，因?yàn)橛袝r(shí)候某個(gè)指標(biāo)異常的時(shí)候，難以得到問(wèn)題相關(guān)因素現(xiàn)場(chǎng)，所以我們針對(duì)slowquery量及io利用率超過(guò)一定閥值去做了一些現(xiàn)場(chǎng)保留工作，比如show processlist，ps aux，top等，并保存在監(jiān)控日志里邊。同時(shí)，也做了checksum的辦法，OS層指標(biāo)增加一些我們急需的但公司網(wǎng)管系統(tǒng)并未涉及的，比如每個(gè)分區(qū)的ioutil等。

• 2012年，為了配合做GCS高可用，做一些時(shí)間同步的檢測(cè)；為了能更方便地去對(duì)比一些DB的性能，聚合性能指標(biāo)在一起，做了特別方便的性能對(duì)比工具。

Game Cloud Storage去哪

圖：Game Cloud Storage去哪

思考GCS去哪，本身也是在想源碼定制這條路該往哪里走？如果大家對(duì)開(kāi)源軟件比較有興趣的話，可以參考我們走過(guò)的路，可以先嘗試簡(jiǎn)單功能的優(yōu)化，然后考慮擴(kuò)展至性，再考慮性能，因?yàn)樾阅軆?yōu)化的挑戰(zhàn)，涉及到mysql底層更復(fù)雜的鎖調(diào)優(yōu)等機(jī)制優(yōu)化，我一直覺(jué)得還是蠻大的。最近一兩年，在線加字段這個(gè)痛點(diǎn)解決折后，我們一直希望能MySQL在保持mysql協(xié)議基本不變的前提下，能像nosql類似MongoDB擴(kuò)展性那么好，在這方面做了一些探索。

我們選用了Spider，一個(gè)分布式的MySQL底層存儲(chǔ)引擎來(lái)解決這個(gè)問(wèn)題，前一兩年開(kāi)始研究這個(gè)Spider，到現(xiàn)在已有超過(guò)10個(gè)業(yè)務(wù)上用了起來(lái)。Spider官方，在最近一兩年也不斷完善，合并到MariaDB 10的正式版本里面。大家如果對(duì)數(shù)據(jù)庫(kù)分布式有需求，同時(shí)不希望開(kāi)發(fā)太多修改，可以考慮MariaDB 10的版本。

圖：運(yùn)維的驅(qū)動(dòng)力

最近業(yè)界有很多運(yùn)維發(fā)展方向的討論，我自身也在思考運(yùn)維的核心驅(qū)動(dòng)力到底是什么。如果我去回顧過(guò)去的一些歷程，我自己考慮運(yùn)維核心的驅(qū)動(dòng)力還是最簡(jiǎn)單兩個(gè)字——問(wèn)題。可能來(lái)自業(yè)務(wù)發(fā)展的快速增大數(shù)據(jù)量，請(qǐng)求并發(fā)增大，或者開(kāi)發(fā)使用整個(gè)存儲(chǔ)的容易程度，或者平時(shí)運(yùn)維的一些問(wèn)題，我們不希望自己那么多通宵處理故障，那么多步驟那么辛苦縮擴(kuò)容。不管在哪家公司，只要我還能夠不斷解決問(wèn)題，可能這個(gè)公司我還能呆得下去；如果沒(méi)有問(wèn)題需要解決，或者是天天時(shí)間都花在其他地方了，可能也就沒(méi)什么意思了。

圖：內(nèi)部平臺(tái)產(chǎn)品方向

我們做這些內(nèi)部平臺(tái)，按目前的人力投入，最重要的還是聚焦支撐內(nèi)部精品大業(yè)務(wù)的發(fā)展。但站在內(nèi)外部技術(shù)平臺(tái)競(jìng)爭(zhēng)加劇的角度，每天都能看到各種各樣渠道吹牛的信息(就像我今天這樣)，都說(shuō)自己很厲害，很強(qiáng)，我們的下一步該怎么走，怎么證明自己的價(jià)值，獲得應(yīng)有的認(rèn)可，這是個(gè)很關(guān)鍵的問(wèn)題。

聽(tīng)了很多業(yè)界大拿的建議，比如葉金榮同學(xué)，平靜的思考之后，我們后續(xù)計(jì)劃或者是策略大概是：首要的，仍然會(huì)站在“巨人的肩膀上”，更好的使用及支持整個(gè)社區(qū)開(kāi)放協(xié)議存儲(chǔ)方案，通過(guò)更為深入研究積累，能提供基本閉環(huán)的服務(wù)支撐能力；第二步，關(guān)于怎么證明團(tuán)隊(duì)價(jià)值，從前幾年的“定制”方向轉(zhuǎn)變到“回到社區(qū)”方向，在那個(gè)更加廣袤的空間去追求些許的認(rèn)可。

更新這個(gè)ppt之前，翻出來(lái)多年前內(nèi)部分享的一頁(yè)ppt，“關(guān)于DB的美好想象”，其中第一點(diǎn)因?yàn)闋砍稑I(yè)務(wù)過(guò)于多樣化邏輯數(shù)據(jù)設(shè)計(jì)，還是沒(méi)做到，第二點(diǎn)做到一點(diǎn)點(diǎn)。

轉(zhuǎn)載于:https://www.cnblogs.com/zping/p/9002659.html

總結(jié)

以上是生活随笔為你收集整理的腾讯游戏DBA团队的发展自白的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。