騰訊遊戲DBA團隊的發展自白

BA這個崗位跟倉管員很像，就是天天給別人發點貨，別人在你這兒放點貨，DBA工做就是把貨儘快給送出去或者讓人家儘快放進來。固然，還有一份重要的工做，就是讓倉庫裏擺放的貨物儘量整齊，這也是倉管員的本職工做，你不能拿到貨往倉庫裏一通亂扔，別人來取貨，又讓別人等上半個小時。

 

圖：騰訊遊戲DBA Team Leader Robin

 

內容提綱：

1. 前輩的積累

2. Game Cloud Storage架構

3. Game Cloud Storage組成

4. Game Cloud Storage去哪

5. 驅動力及方向探討

前輩的積累：三類遊戲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。

最後，知足切換的前置條件包括如下幾方面：

1. show slave status, 獲取binlog獲取及本地relay執行對比；

2. Checksum(7天內)不一致塊數量，小於5個塊可進行切換；

3. Slave落後Master時間, 小於10秒爲可進行切換；

4. 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的美好想象」，其中第一點由於牽扯業務過於多樣化邏輯數據設計，仍是沒作到，第二點作到一點點。