編者按：
一直以來(lái)，中國(guó)網(wǎng)游在世界上都處于舉足輕重的地位。從最早的端游到頁(yè)游再到手游，不僅市場(chǎng)用戶(hù) 爆發(fā)式增長(zhǎng)，近15年來(lái)網(wǎng)游技術(shù)的發(fā)展也是無(wú)比迅速。和單機(jī)游戲不同，網(wǎng)游除了游戲制作本身以外還牽涉到服務(wù)器端，再好的游戲如果出現(xiàn)鏈接、延遲等問(wèn)題時(shí) 也會(huì)造成巨大損失，這時(shí)候游戲運(yùn)維便發(fā)揮了舉足輕重的作用。中國(guó)網(wǎng)游的發(fā)展史，其實(shí)也是游戲運(yùn)維的變革史，今天便由經(jīng)典武俠手游《大掌門(mén)》運(yùn)維掌門(mén)人吳啟 超來(lái)向我們講述，進(jìn)入游戲領(lǐng)域10余年來(lái)的風(fēng)風(fēng)雨雨。
有服務(wù)器的地方就有運(yùn)維
如今我們說(shuō)到游戲，可能想到的是火爆異常的VR，辦公室里一言不合帶上眼鏡就地開(kāi)打；亦或是剛剛虐了李世石的AlphaGo，揚(yáng)言要挑戰(zhàn)《星際爭(zhēng)霸2》“教主”Flash。然而，除去這些還有一個(gè)游戲行業(yè)不可避免的潮流正在發(fā)生，那便是網(wǎng)絡(luò)化。
這里說(shuō)的不止是網(wǎng)游，前不久育碧旗下網(wǎng)游大作《全境封鎖》上線時(shí)鬧出個(gè)小笑話：由于很多國(guó)內(nèi)玩 家下載之前沒(méi)注意是網(wǎng)游，下意識(shí)的以為育碧的游戲肯定是單機(jī)，好不容易下完之后才發(fā)現(xiàn)玩不上，進(jìn)而發(fā)生了不少的騷動(dòng)。這不是***個(gè)發(fā)生這種情況的傳統(tǒng)游戲 廠商，肯定也不是***一個(gè)，很多有名的游戲公司都在做類(lèi)似的嘗試，Popcap的《植物大戰(zhàn)僵尸：花園戰(zhàn)爭(zhēng)》系列，暴雪的《暗黑3》等，甚至那些還有單機(jī) 成分的大作也早就開(kāi)始網(wǎng)絡(luò)化：大名鼎鼎的《GTA5》、FPS風(fēng)向標(biāo)《使命召喚》系列和《戰(zhàn)地》系列，網(wǎng)絡(luò)聯(lián)機(jī)部分的比重也在一年一年的增加。
網(wǎng)絡(luò)聯(lián)機(jī)，意味著玩家需要登錄官方服務(wù)器，“有人的地方就有江湖”，這句話說(shuō)的不僅是網(wǎng)游里的恩怨情仇，還包括游戲外的種種：“有服務(wù)器的地方就有運(yùn)維。”這便是今天我們要說(shuō)的話題——游戲運(yùn)維。
游戲運(yùn)維編年史
1，石器時(shí)代：端游
想要了解如今的游戲運(yùn)維，不得不從早期的端游運(yùn)維開(kāi)始說(shuō)起。對(duì)于08年入行端游，11年經(jīng)歷過(guò)頁(yè)游***14年全面接觸手游的吳啟超來(lái)說(shuō)，這幾年的游戲運(yùn)維經(jīng)歷讓他深切感受到運(yùn)維思路的巨大轉(zhuǎn)變。
1.1 端游的運(yùn)維工種：IDC運(yùn)維、系統(tǒng)型運(yùn)維、網(wǎng)絡(luò)運(yùn)維、業(yè)務(wù)型運(yùn)維、運(yùn)維值班等。各個(gè)工種分工各有側(cè)重。
IDC運(yùn)維：裝機(jī)、換配件、扛著2U的服務(wù)器全國(guó)各個(gè)機(jī)房來(lái)回跑。
系統(tǒng)運(yùn)維：安裝各種軟件，調(diào)試各種不兼容的軟件，在各種版本的Linux、Windows上。
網(wǎng)絡(luò)運(yùn)維：二層交換、三層交換、四層交換，還要區(qū)分華為、思科。
業(yè)務(wù)運(yùn)維：24點(diǎn)維護(hù)，零晨2點(diǎn)維護(hù)，零晨5點(diǎn)維護(hù)，早上7點(diǎn)維護(hù)……
運(yùn)維值班：0點(diǎn)盯著屏幕打電話，1點(diǎn)盯著屏幕打電話，2點(diǎn)盯著屏幕打電話……
運(yùn)維開(kāi)發(fā)：寫(xiě)著各種的邏輯，因?yàn)闃I(yè)務(wù)、網(wǎng)絡(luò)環(huán)境、BUG、剛剛幫忙扛完服務(wù)器。
1.2 端游運(yùn)維業(yè)務(wù)范圍：在端游時(shí)代，大部分游戲公司都是自主做各種業(yè)務(wù)環(huán)境，做各種游戲業(yè)務(wù)需要的各種環(huán)境。
資產(chǎn)管理：服務(wù)器、交換機(jī)、各種服務(wù)分布位置，端口等。
下載服務(wù)器：搭建BT集群，做種子、分發(fā)，供玩家下載游戲客戶(hù)端使用。
靜態(tài)緩存服務(wù)器：squid + apache|nginx
郵件服務(wù)器：postfix +sasl +ssl 收發(fā)服務(wù)、反垃圾郵件服務(wù)。
網(wǎng)絡(luò)質(zhì)量監(jiān)控：somkingping各個(gè)機(jī)房的交換，各個(gè)安放點(diǎn)服務(wù)器。
配置管理：nginx 、apache、lighttpd、MySQL。
批量管理：ssh公鑰/私鑰 。
監(jiān)控管理：nagios、catcai 然后是c|perl|python|shell +rrdtool各種業(yè)務(wù)監(jiān)控圖。
1.3 端游游戲服務(wù)器架構(gòu)：一般來(lái)講都是以一組服務(wù)器集群為一個(gè)區(qū)服單位，單機(jī)上的進(jìn)程提供不同的服務(wù)。
傳統(tǒng)運(yùn)維，任務(wù)道遠(yuǎn)，正因?yàn)橛羞^(guò)去那些年的翻譯文檔，兼顧整合方案，以及大批分享技術(shù)的前輩、社區(qū)，踩著前輩一步一個(gè)坑的走過(guò)來(lái)，才能有今天的運(yùn)維的局面。
2，青銅時(shí)代：頁(yè)游
在2011-2013年左右的頁(yè)游運(yùn)維，游戲市場(chǎng)處于探索期，其實(shí)運(yùn)維也處于探索期。端游時(shí)代 每個(gè)新服都要經(jīng)歷上架、裝系統(tǒng)，裝服務(wù)的過(guò)程，一般一到兩周可以上線一個(gè)區(qū)服，對(duì)于端游高粘性低流動(dòng)的特性來(lái)說(shuō)可能還好，但是當(dāng)頁(yè)游出現(xiàn)時(shí)，轉(zhuǎn)變給運(yùn)維帶 來(lái)的沖擊無(wú)法估量。頁(yè)游時(shí)代1天開(kāi)100多個(gè)新服的概念，是傳統(tǒng)端游運(yùn)維所不能理解的。當(dāng)時(shí)的運(yùn)維認(rèn)為頁(yè)游就是把所有服務(wù)器實(shí)現(xiàn)自動(dòng)部署服務(wù)，同時(shí)搭配運(yùn) 維自動(dòng)部服工具就可以了。但事實(shí)上如果在開(kāi)服時(shí)一組一組的使用物理服務(wù)器，開(kāi)服速度根本跟不上，資源浪費(fèi)還非常巨大，兩周后用戶(hù)留存率僅剩5%-7%。成 本巨大虧空，急需技術(shù)轉(zhuǎn)型，這個(gè)時(shí)間點(diǎn)上出現(xiàn)了兩種概念影響了以后的手游以及云的發(fā)展。
1. 虛擬化技術(shù)
在2010年11月份左右， kvm出現(xiàn)在RHEL6中，去掉了RHEL 5.X系列中集成的Xen。正是這一次虛擬化技術(shù)的轉(zhuǎn)型，而且當(dāng)時(shí)市場(chǎng)的需要，在2011年-2012年掀起了一場(chǎng)私有云建設(shè)的風(fēng)潮。在實(shí)踐過(guò)程中，優(yōu)點(diǎn) 很多，但暴露的缺點(diǎn)也不少。在端游占主要市場(chǎng)的情況下，實(shí)踐過(guò)程中表現(xiàn)出來(lái)的不適尤其明顯。
a. 虛擬機(jī)時(shí)鐘不準(zhǔn)
b. 虛擬機(jī)網(wǎng)卡，超負(fù)荷down、丟包
c. 多虛擬機(jī)間爭(zhēng)搶cpu、內(nèi)存
d. 多虛擬機(jī)間的安全訪問(wèn)，虛擬機(jī)與物理機(jī)間的安全管控
e. 對(duì)于關(guān)系型數(shù)據(jù)庫(kù)磁盤(pán)讀寫(xiě)慢問(wèn)題突出。
f. 等等
以上幾點(diǎn)隨著時(shí)間的推移有的已經(jīng)然后解決，有的換上了代替方案。時(shí)至今日，端游在單純的虛擬云上部署仍是問(wèn)題，但是隨著物理、虛掩混合云出現(xiàn)，這個(gè)局面應(yīng)該可以被打破。
2. 社交化的頁(yè)游
社區(qū)化的頁(yè)游戲，為什么這樣說(shuō)呢，因?yàn)楫?dāng)時(shí)更多的頁(yè)游信托社區(qū)入口，導(dǎo)入用戶(hù)流量，當(dāng)時(shí)最火的 應(yīng)該是人人網(wǎng)（校內(nèi)網(wǎng)）的農(nóng)場(chǎng)偷菜。然后是DZ論壇一堆農(nóng)場(chǎng)插件襲卷全國(guó)，當(dāng)然這一切都是為了增加用戶(hù)粘稠度。但是也影響了頁(yè)游技術(shù)的選型，當(dāng)時(shí)基本上大 家不約而的選用了于社區(qū)相同的LAMP的技術(shù)，從而降低開(kāi)發(fā)成本及接入成本。當(dāng)然現(xiàn)使用JAVA SSH2架構(gòu)的頁(yè)游也有。除技術(shù)選型外，同時(shí)還帶入了另一個(gè)概念：聯(lián)運(yùn)。聯(lián)運(yùn)這個(gè)概念在頁(yè)游時(shí)代對(duì)于端游運(yùn)維就像一個(gè)惡夢(mèng)，不同區(qū)服要隨時(shí)跨服站，不同區(qū) 服要隨時(shí)可以合區(qū)，所有數(shù)據(jù)不再是以物理服務(wù)器為單位，而是要逐條打標(biāo)簽，再也看不到賬號(hào)，只能拿著一串長(zhǎng)長(zhǎng)的KEY，四處兌換，然后拿著不知道所謂的表 標(biāo)問(wèn)第三方…….
在這個(gè)時(shí)期，是運(yùn)維開(kāi)發(fā)的爆發(fā)年，隨著虛擬化技術(shù)的推廣，越來(lái)的越多的運(yùn)維開(kāi)始接觸自動(dòng)化運(yùn)維的概念，開(kāi)始了自動(dòng)化運(yùn)維的奮斗之路，開(kāi)始了以項(xiàng)目管理的角度看待運(yùn)維腳本開(kāi)發(fā)。
3，黃金時(shí)代：手游
隨著私有云轉(zhuǎn)為公有云、云時(shí)代推動(dòng)著云計(jì)算以及移動(dòng)互聯(lián)網(wǎng)的發(fā)展，網(wǎng)游行業(yè)慢慢進(jìn)入了手游黃金時(shí)代，云時(shí)代的變革不僅挑戰(zhàn)了整個(gè)游戲行業(yè)，也挑戰(zhàn)了游戲運(yùn)維。
3.1 手游的運(yùn)維工種：系統(tǒng)型運(yùn)維，業(yè)務(wù)型運(yùn)維。
3.2 手游運(yùn)維業(yè)務(wù)范圍：阿里云、 亞馬遜 、UCloud、 藍(lán)汛CDN、 聽(tīng)云監(jiān)控。
3.3 手游游戲服務(wù)器架構(gòu)：一般來(lái)講都是以一組服務(wù)器集群為一個(gè)平臺(tái)單位，不同的集群提供不同的服務(wù)。
手游的架構(gòu)理念是提供一組虛擬服務(wù)器，當(dāng)短連接的時(shí)候，每開(kāi)一組服，將玩家引導(dǎo)到Web集群， 隨后被分配到不同的MongoDB，數(shù)據(jù)緩存用在Redis。當(dāng)***個(gè)服務(wù)器玩家請(qǐng)求DB時(shí)，會(huì)落到Mongo1上；當(dāng)開(kāi)第二個(gè)服的時(shí)候，還是將玩家引導(dǎo) 到Mongo1上；以此類(lèi)推直到運(yùn)維發(fā)現(xiàn)壓力累積到一定程度時(shí)，便會(huì)新開(kāi)一組MongoDB，Web集群也是如此但只有性能不夠時(shí)才會(huì)添加，一般情況下， 每50個(gè)新服可能需要添加1個(gè)MongoDB。這便實(shí)現(xiàn)并解釋了當(dāng)時(shí)在頁(yè)游里希望實(shí)現(xiàn)的快速開(kāi)服方法。
到此為止我們已經(jīng)回顧了一遍游戲運(yùn)維從端游到頁(yè)游再到手游的演變過(guò)程，不難看出，手游對(duì)于區(qū)服 的架構(gòu)概念不同于端游：端游認(rèn)為一個(gè)物理集群是一個(gè)服，而手游認(rèn)為一個(gè)Web請(qǐng)求落到相應(yīng)的數(shù)據(jù)庫(kù)上就是一個(gè)服。這樣的好處是開(kāi)服合服都簡(jiǎn)單，如果前五十 組服務(wù)器需要合并，實(shí)現(xiàn)起來(lái)很容易，因?yàn)橥粋€(gè)DB的數(shù)據(jù)是互通的，所以只需發(fā)一個(gè)公告，服務(wù)器加標(biāo)識(shí)即可，不需要進(jìn)行物理操作也不需要數(shù)據(jù)遷移。
游戲運(yùn)維***指南
說(shuō)完了游戲運(yùn)維的歷史，我們要開(kāi)始今天的重頭戲，如何做好游戲運(yùn)維？這里就用吳啟超的一個(gè)冷笑 話作為開(kāi)始：運(yùn)維為什么存在？a，有服務(wù)器；b，因?yàn)檠邪l(fā)忙不過(guò)來(lái)。不管是笑沒(méi)笑，運(yùn)維確實(shí)因?yàn)樯厦鎯蓚€(gè)原因才會(huì)誕生的。那么回到正題，想成為玩轉(zhuǎn)上千服 務(wù)器的游戲運(yùn)維應(yīng)該怎么樣做呢？系統(tǒng)部運(yùn)維構(gòu)建大致如下圖：
1，構(gòu)建CMDB
21世紀(jì)什么最重要？信息最重要！運(yùn)維所需信息要涉及：機(jī)房、物理服務(wù)器、虛擬機(jī)、交換機(jī)、網(wǎng) 絡(luò)、承載業(yè)務(wù)、業(yè)務(wù)配置、承載服務(wù)進(jìn)程、端口等信息。不管是自己采購(gòu)還是購(gòu)買(mǎi)云服務(wù)，物理服務(wù)器和虛擬服務(wù)器都做為資產(chǎn)存在，在采購(gòu)后錄入相關(guān)的資產(chǎn)管 理，給它打上標(biāo)簽，屬于哪個(gè)游戲，哪個(gè)平臺(tái)，這樣不同游戲平臺(tái)間就不能混用服務(wù)器了。然后，是再給不同的服務(wù)器標(biāo)識(shí)它承擔(dān)的業(yè)務(wù)角色，比如它是 MongoDB，我們需要打上的標(biāo)簽會(huì)是大掌門(mén)-APPSTORE-MongoDB-主庫(kù)-90000端口-***組服務(wù)。這樣一個(gè)基礎(chǔ)信息錄入就完成了。
這樣的信息只要是用來(lái)將來(lái)批量化部署、管理服務(wù)器使用，以及當(dāng)出現(xiàn)故障時(shí)，運(yùn)維可以很方便的查詢(xún)相當(dāng)?shù)姆?wù)器以及服務(wù)信息。但是數(shù)據(jù)的及時(shí)性、準(zhǔn)確性、可檢查是一個(gè)難點(diǎn)。
2，集中批量化管理
CMDB不是TXT文件，而是要變成EXE文件。運(yùn)維在面臨大量服務(wù)器的情況下，批量化工具的 出現(xiàn)成為必須的結(jié)果，在日常的工作當(dāng)中需要把其流程固化下來(lái)，為完成批量化安裝、管理打下基礎(chǔ)。大掌門(mén)喜歡使用 ssh sshpass paramiko libssh2這些基礎(chǔ)的技術(shù)做批量管理。原因是不用安裝簡(jiǎn)單、穩(wěn)定、安全、可控。當(dāng)然吳啟超也表示推薦大家使用在市面上流程行puppet、 Ansible、SaltStack等技術(shù)，為什么？簡(jiǎn)單、簡(jiǎn)單、簡(jiǎn)單！下圖就是在做自動(dòng)化半自動(dòng)化運(yùn)維過(guò)程中的模型。
批量管理的難點(diǎn)在于：
a. 命令的并發(fā)執(zhí)行，要控制各點(diǎn)的超時(shí)時(shí)間
b. 執(zhí)行過(guò)程中，不同功能的不同權(quán)限要求
c. 數(shù)據(jù)通信安全的保證，以及能夠正常解析數(shù)據(jù)指令
d. 人員賬號(hào)權(quán)限管理，權(quán)限分發(fā)及回收
e. 物理服務(wù)器、云服務(wù)器統(tǒng)一化安裝及老項(xiàng)目改造
f. 網(wǎng)絡(luò)質(zhì)量不可靠的情況下，執(zhí)行不完整的情況下業(yè)務(wù)功能回滾。
3，性能與業(yè)務(wù)監(jiān)控
應(yīng)用性能監(jiān)控
1、每天都會(huì)對(duì)服務(wù)器進(jìn)行上線，升級(jí)等操作，每款游戲在一個(gè)平臺(tái)的集群數(shù)在幾十個(gè)到幾百個(gè)不等 （根據(jù)平臺(tái)大?。Ｒ虼嗣刻炀S護(hù)和升級(jí)服務(wù)器壓力極大，服務(wù)器異?；蝽憫?yīng)慢等問(wèn)題的發(fā)生會(huì)給用戶(hù)體驗(yàn)帶來(lái)傷害。 這樣的隱患在于一旦發(fā)生游戲關(guān)服之后就必須對(duì)玩家進(jìn)行游戲中貨幣和元寶的賠償，平均每個(gè)玩家補(bǔ)償?shù)脑獙氈辽僭?元以上，游戲幣和各類(lèi)游戲道具若干，以此類(lèi) 推由于服務(wù)器故障造成的損失可想而知。
2、大掌門(mén)使用了聽(tīng)云Server，能夠?qū)Ψ?wù)器響應(yīng)慢和不可用進(jìn)行定位，查看慢應(yīng)用追蹤和Web應(yīng)用過(guò)程功能，能夠?qū)崟r(shí)定位消耗資源***的代碼和語(yǔ)句，這樣就能幫助實(shí)時(shí)進(jìn)行有針對(duì)性的調(diào)整和優(yōu)化，并且可以快速定位問(wèn)題時(shí)間，最快能到分鐘級(jí)別。
3、發(fā)生高并發(fā)、服務(wù)器壓力激增的情況時(shí)，平時(shí)運(yùn)行正常的服務(wù)器異常概率大幅增加，日?？赡艿?性能瓶頸點(diǎn)會(huì)被成倍放大，這就需要實(shí)時(shí)定位和解決性能瓶頸點(diǎn)，和提前進(jìn)行預(yù)防改善。一般來(lái)說(shuō)，傳統(tǒng)日志收集方式耗時(shí)耗力，效果非常不好，大掌門(mén)用了聽(tīng)云 Server后，可以進(jìn)行1分鐘級(jí)定位能迅速有效發(fā)現(xiàn)瓶頸點(diǎn)。同時(shí)還結(jié)合了聽(tīng)云Network的壓測(cè)功能，能夠在服務(wù)器上線前提前發(fā)現(xiàn)到高壓力下的瓶頸 點(diǎn)，提前預(yù)防，避免由于高并發(fā)出現(xiàn)的服務(wù)器瓶頸
4、還有一種性能情況需要提前預(yù)防，游戲公司盈利在于玩家的充值，對(duì)于官網(wǎng)上從登陸到充值全流 程的成功率業(yè)務(wù)部門(mén)極其關(guān)注，玩家點(diǎn)擊跳轉(zhuǎn)的失敗會(huì)直接導(dǎo)致充值付費(fèi)用戶(hù)的轉(zhuǎn)化率。對(duì)此，大掌門(mén)通過(guò)聽(tīng)云Network的事務(wù)流程功能能夠?qū)崟r(shí)對(duì)事物流程 進(jìn)行警報(bào)，幫助業(yè)務(wù)部門(mén)提升用戶(hù)充值的轉(zhuǎn)化率
業(yè)務(wù)監(jiān)控
除了性能和硬件監(jiān)控之外，對(duì)于游戲業(yè)務(wù)運(yùn)轉(zhuǎn)是否正常也需要建立一套標(biāo)準(zhǔn)去評(píng)判。
對(duì)此，大掌門(mén)開(kāi)發(fā)了一套適用于全公司所有的游戲的統(tǒng)一登陸、充值、交易平臺(tái)，解決了前端的 SDK接入的問(wèn)題，一個(gè)所有游戲或第三方的API接口統(tǒng)一接入的平臺(tái)。在做業(yè)務(wù)型監(jiān)控時(shí)，運(yùn)維會(huì)要求后端開(kāi)發(fā)人員寫(xiě)一個(gè)特定賬號(hào)，在訪問(wèn)現(xiàn)有系統(tǒng)時(shí)，會(huì)完 整的走一遍業(yè)務(wù)流，這樣就可以看到需要的業(yè)務(wù)數(shù)字。
4，數(shù)據(jù)倉(cāng)庫(kù)搭建
上圖為大掌門(mén)數(shù)據(jù)倉(cāng)庫(kù)的結(jié)構(gòu)圖，由于數(shù)據(jù)倉(cāng)庫(kù)搭建的話題比較大，只是簡(jiǎn)單的從數(shù)據(jù)集市的角度來(lái)聊聊，DM指的是數(shù)據(jù)集市。由于數(shù)據(jù)集市需要面對(duì)不同的人群，因此在數(shù)據(jù)倉(cāng)庫(kù)中需要建立不同的數(shù)據(jù)集市以面對(duì)各方的查詢(xún)需求，進(jìn)而對(duì)數(shù)據(jù)按照業(yè)務(wù)類(lèi)型進(jìn)行分類(lèi)。
1、財(cái)務(wù)：關(guān)心月度充值數(shù)據(jù)
2、商務(wù)：關(guān)心渠道結(jié)算數(shù)據(jù)
3、運(yùn)營(yíng)：關(guān)心用戶(hù)登陸量、轉(zhuǎn)化率、留存率、平臺(tái)充值額
4、產(chǎn)品：關(guān)心功能熱度、用戶(hù)體驗(yàn)
5、客服：關(guān)心所有數(shù)據(jù)及玩家屬性
對(duì)于數(shù)據(jù)方面，運(yùn)維的壓力來(lái)自于需要貫穿及掌握所有的數(shù)據(jù)，并且為所有部門(mén)服務(wù)。簡(jiǎn)單的以下圖的ETL為例：
數(shù)據(jù)對(duì)于運(yùn)維的痛點(diǎn)：
1、日志切割工作誰(shuí)做？研發(fā)還是運(yùn)維。日志切割按什么規(guī)則？大小還是日期？
2、使用什么工具進(jìn)行日志收集？scribe 還是flume 還是 sls？
3、數(shù)據(jù)的準(zhǔn)確性誰(shuí)來(lái)保證？日志內(nèi)容不對(duì)、切割不對(duì)、傳輸丟失、入hadoop過(guò)濾
4、數(shù)據(jù)ETL過(guò)程監(jiān)控，如果出現(xiàn)數(shù)據(jù)丟失怎么辦？
5、數(shù)據(jù)采集怎么樣盡可能的保證并發(fā)的采集，縮短時(shí)間。
6、數(shù)據(jù)的出現(xiàn)丟失或錯(cuò)誤，整體數(shù)據(jù)回滾。誰(shuí)來(lái)保證？怎么保證？
7、大量數(shù)據(jù)下，核對(duì)數(shù)據(jù)丟失情況怎么樣核對(duì)？用什么方法？
那大掌門(mén)又是如何解決這些問(wèn)題的呢：
1、 將數(shù)據(jù)日志進(jìn)行切割（按照業(yè)務(wù)打包日志）并合理命名。比如A登陸日志，B充值日志，C消費(fèi)日志。分門(mén)別類(lèi)進(jìn)行打包后，對(duì)數(shù)據(jù)每5分鐘切割1次，并生成md5包。
2、 按照劃分IDC Region。原來(lái)從本機(jī)向外傳輸數(shù)據(jù)會(huì)占用大量帶寬，對(duì)于本身CPU的消耗大的話都會(huì)影響游戲的運(yùn)行?，F(xiàn)在按照IDC region做出劃分，每個(gè)區(qū)域中會(huì)有1-3個(gè)中心存儲(chǔ)服務(wù)器。將切割下來(lái)的數(shù)據(jù)放到中心存儲(chǔ)上，劃分成Aip1、Aip2、Aip3等md5壓縮包，此 處無(wú)需做合并（原因見(jiàn)3）。
3、 建立下載任務(wù)。建立好任務(wù)列表后，對(duì)每5分鐘的壓縮包進(jìn)行下載?？紤]到如果上面的步驟做了合并的話就可能會(huì)產(chǎn)生在傳輸?shù)臅r(shí)候丟數(shù)據(jù)卻無(wú)法確定的情況，因此2步驟無(wú)需對(duì)數(shù)據(jù)進(jìn)行合并。
4、將下載后的任務(wù)加到Hive數(shù)據(jù)倉(cāng)庫(kù)里。將當(dāng)天的數(shù)據(jù)放到MySQL中，之前的數(shù)據(jù)放到 Hive里。當(dāng)運(yùn)營(yíng)提出數(shù)據(jù)需求時(shí)便可以到Hive中下載數(shù)據(jù)。即使數(shù)據(jù)出現(xiàn)錯(cuò)誤，按照上面建立的每5分鐘的任務(wù)列表也可以重新以規(guī)定時(shí)間點(diǎn)將數(shù)據(jù)壓縮包 重新拉回來(lái)。并且該流程可以按照正向、反向雙向進(jìn)行。
采用5分鐘壓縮包的另外一個(gè)原因在于每臺(tái)服務(wù)器每天產(chǎn)生業(yè)務(wù)日志大概有5-6G的數(shù)據(jù)，分到5分鐘后，切割完每個(gè)文件就是20M－30M，壓縮后只占用很少的空間。這樣就解決了占用大量帶寬的問(wèn)題。
5、數(shù)據(jù)傳輸后需將數(shù)據(jù)放到數(shù)據(jù)倉(cāng)庫(kù)（DW）中，數(shù)據(jù)下載完畢后會(huì)根據(jù)文件進(jìn)行存儲(chǔ)，當(dāng)天的數(shù) 據(jù)按照5分鐘1個(gè)壓縮包進(jìn)入MySQL，MySQL則進(jìn)入當(dāng)天的查詢(xún)。在數(shù)據(jù)倉(cāng)庫(kù)中，數(shù)據(jù)包按游戲及平臺(tái)進(jìn)行分類(lèi)，這種格局的安排為了在并發(fā)時(shí)更好的運(yùn) 行。由于游戲與游戲之間是隔離的，因此按照這種模式是為了保證數(shù)據(jù)進(jìn)行順利并發(fā)。
