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团队的发展自白的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。