資訊專欄INFORMATION COLUMN
摘要：繼而取名紅色警戒復(fù)興。在經(jīng)過了將近一年的蟄伏后，作為紅色警戒復(fù)興的聯(lián)合創(chuàng)始人，終于有幸在今年月份見證他的第一次公開亮相。至此，我們初步斷定，癥結(jié)點(diǎn)在深層嵌套文檔導(dǎo)致的數(shù)據(jù)多層尋址引發(fā)的。
前言
在2016年5月份的某一天，我和菠蘿同學(xué)懷著對(duì)昔日《紅警95》的緬懷之情，相約脫胎于開源項(xiàng)目OpenRA，來自制Server、Web、個(gè)人系統(tǒng)等，重現(xiàn)《紅警95》的昔日光芒。繼而取名《紅色警戒：復(fù)興》。
在經(jīng)過了將近一年的蟄伏后，作為《紅色警戒：復(fù)興》的聯(lián)合創(chuàng)始人，終于有幸在今年4月份見證他的第一次公開亮相。
《紅色警戒：復(fù)興》官方網(wǎng)站
為何選用MongoDB在構(gòu)建項(xiàng)目之初，曾以為的天馬行空、偉大藍(lán)圖在實(shí)際操作過程中遇到了非常多的阻礙。脫胎于開源項(xiàng)目，用.NET實(shí)現(xiàn)的游戲引擎，當(dāng)我們還在為windows服務(wù)器不穩(wěn)定而糾結(jié)的時(shí)候，MS發(fā)布了.NET CORE！這一振奮人心的事情立馬讓我們決定去大干一番！
（中間省略1萬字……）
然后在實(shí)際開發(fā)過程中，遇到了一個(gè)比較棘手的問題。我們希望記錄下戰(zhàn)斗中所有的戰(zhàn)斗數(shù)據(jù)以供后期采用統(tǒng)計(jì)分析方法對(duì)收集來的大量數(shù)據(jù)進(jìn)行分析，提取有用信息并形成結(jié)論而對(duì)數(shù)據(jù)加以詳細(xì)研究、概括總結(jié)。
我們先來看一個(gè)gif圖
從該gif中，我們可以看到紅色玩家單位中有大量的坦克并摧毀了綠色玩家的建筑、士兵、坦克等單位，這一場(chǎng)戰(zhàn)斗的數(shù)據(jù)是會(huì)直接記錄到我們的MongoDB中，最后當(dāng)游戲結(jié)束時(shí)作統(tǒng)一處理。
這里考驗(yàn)數(shù)據(jù)庫(kù)性能的點(diǎn)在于，我們需要記錄這一回合中，紅色玩家有多少A單位、B單位……，其中包括建筑、士兵、坦克、飛機(jī)、防御單位等。在游戲過程中的所有游戲數(shù)據(jù)我們都是存mongo的，考慮到大量的計(jì)算，MySQL無法勝任。
因此最終的DB選型就是MongoDB作為游戲中的數(shù)據(jù)計(jì)算容器，MySQL作為最終的數(shù)據(jù)落盤容器。這也是許多項(xiàng)目采用的一種MongoDB+MySQL的解決方案。
設(shè)計(jì)模式惹的禍在使用MongoDB記錄數(shù)據(jù)的時(shí)候，通過OPS記錄，發(fā)現(xiàn)當(dāng)游戲進(jìn)度推進(jìn)至20分鐘后（注意這個(gè)時(shí)間點(diǎn)，由于游戲特性，決定了往往在激戰(zhàn)20分鐘后，會(huì)出現(xiàn)經(jīng)濟(jì)大于生產(chǎn)的情況），兵種數(shù)量急劇增加，MongoDB CPU負(fù)載就會(huì)驟然飆升，而這僅僅是在測(cè)試環(huán)境，若投入生產(chǎn)，，這種情況一般我是采取零容忍的，接下來就是一段改造的過程。
首先一起了解下起初的設(shè)計(jì)結(jié)構(gòu)：
{
"_id" : ObjectId("58ecdc0b5003d2a379b871df"),
"profileId" : 1,
"gameId" : 1,
"units" : {
"soldiers" : {
"Rifle" : 23,
"Grenadier" : 46
},
"vehicles" : {
"V2" : 15,
"Light" : 7
}
},
"money" : {
"earned" : 12345,
"spent" : 54321
}
}
以上Json是游戲中記錄的部分的戰(zhàn)斗數(shù)據(jù)結(jié)構(gòu)。需求很簡(jiǎn)單，需要記錄下實(shí)時(shí)的玩家數(shù)據(jù)，比如士兵中有一種兵種類型Rifle，當(dāng)前數(shù)量為23個(gè)；V2遠(yuǎn)程坦克有15輛等等。
為什么會(huì)造成數(shù)據(jù)庫(kù)的負(fù)載過高呢？目前發(fā)現(xiàn)一個(gè)現(xiàn)象，當(dāng)數(shù)據(jù)量不是特別大的時(shí)候（也就是之前所強(qiáng)調(diào)的20分鐘這個(gè)零界值），服務(wù)器的cpu load并沒有表現(xiàn)出異常，而一旦過了零界值，在經(jīng)濟(jì)遠(yuǎn)大于生產(chǎn)的情況下，玩家往往會(huì)持續(xù)輸出戰(zhàn)斗單位、防御單位、基本建筑等。這個(gè)階段，我們的MongoDB往往是在做高頻率的update操作，且是對(duì)同一條數(shù)據(jù)中的不同數(shù)值進(jìn)行操作。
分析排除NUMA啟動(dòng)。
由于官方有明確表示，因此我也關(guān)閉了NUMA，具體NUMA對(duì)MongoDB的影響可參照 MongoDB Manual 關(guān)于NUMA的解釋
這里引用一段：
Running MongoDB on a system with Non-Uniform Access Memory (NUMA) can cause a number of operational problems, including slow performance for periods of time and high system process usage.
排除CPU分配不均。
鑒于MongoDB Manual中有提到對(duì)于云服務(wù)或者虛機(jī)的使用注意事項(xiàng)，因?yàn)槲覀円蚕穹?wù)商確認(rèn)過了，不存在如下引用 MongoDB on Virtual Environments
When using MongoDB with KVM, ensure that the CPU reservation does not exceed more than 2 virtual CPUs per physical core.
排查slow log
無論計(jì)算機(jī)發(fā)展的如何遵循摩爾定律，馮諾依曼體系結(jié)構(gòu)是不會(huì)變的。也就是說我們的cpu是順序執(zhí)行的。
因此在排除了前面2種情況后，我們需要確認(rèn)的是是否存在慢查詢了。
也就是在slow log中，我們發(fā)現(xiàn)大量的10s以上的update操作。這無疑使我們更接近了真相。因?yàn)檎嫦嘀挥幸粋€(gè)。
為什么在零界值前cpu load并沒有表現(xiàn)出過載的情況？對(duì)于update涉及到的查詢條件都已經(jīng)加上了索引，但并未有明顯改善。
但是慢查詢是擺在那里的，不離不棄。我們嘗試著對(duì)profileId進(jìn)行頻繁update，但CPU顯然沒有任何波動(dòng)。
至此，我們初步斷定，癥結(jié)點(diǎn)在深層嵌套文檔導(dǎo)致的數(shù)據(jù)多層尋址引發(fā)的。
Embedded data models allow applications to store related pieces of information in the same database record. As a result, applications may need to issue fewer queries and updates to complete common operations.
顯然我們錯(cuò)誤的理解了MANUAL中對(duì)于embedded doc 的用法。
通過抓取currentOp，進(jìn)一步確認(rèn)，問題就在update的內(nèi)嵌文檔上。
縱觀這條戰(zhàn)斗數(shù)據(jù)，細(xì)心的你一定發(fā)現(xiàn)了，我們的數(shù)據(jù)嵌套非常深，而對(duì)于這條數(shù)據(jù)中最需要計(jì)算的部分是藏在最里面的，3層嵌套的計(jì)算對(duì)于mongodb來說是非常吃力的，需要耗費(fèi)巨大的cpu去做這件事情。
經(jīng)過對(duì)業(yè)務(wù)需求的再整理，達(dá)成一個(gè)共識(shí)，可以暫時(shí)拋棄對(duì)于兵種的分類，只記錄實(shí)際存在的數(shù)據(jù)。
基于以上思路，我們得出了如下的model：
{
"_id" : ObjectId("58ecdeed5003d2a379b871e0"),
"profileId" : 1,
"gameId" : 1,
"Rifle" : 23,
"Grenadier" : 46,
"V2" : 15,
"Light" : 7,
"earned" : 12345,
"spent" : 54321
}
通過改造data model，除去兵種的分類，只對(duì)已有的單位進(jìn)行update、新增的兵種進(jìn)行初始化即可。
從3層嵌套中解放出來，放在一級(jí)目錄下，再次測(cè)試，cpu毫無壓力。
至此，一次關(guān)于MongoDB的Schema Design/Data Model改造到此告一段落。
最后附上原子彈的gif，這個(gè)動(dòng)圖其實(shí)也是對(duì)我們mongodb的一次考驗(yàn)，需要瞬時(shí)減去相對(duì)應(yīng)數(shù)量的單位。
最后歡迎大家來一起體驗(yàn)我們的《紅色警戒：復(fù)興》！
也歡迎志同道合的小伙伴通過 官方網(wǎng)站-加入我們 來加入我們的團(tuán)隊(duì)，為復(fù)興紅警努力！
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/19073.html
摘要：紅色警戒復(fù)興的聯(lián)合創(chuàng)始人，中國(guó)第位獲得者，大中華區(qū)核心成員。給我吹了一通后，我感覺被洗腦了，當(dāng)年還是很吃香的啊，傳聞年月入。不要滿足于現(xiàn)狀，要勇于走出舒適區(qū)，嘗試不同的東西。 showImg(https://img-blog.csdnimg.cn/20190304200609292.jpeg#pic_center); 作者介紹：90后生人/男/二本本科/世界500強(qiáng)技術(shù)主管 1.引言 ...
摘要：大家都知道，做我們開發(fā)這行的，最核心的競(jìng)爭(zhēng)力就是學(xué)習(xí)能力。學(xué)習(xí)只要找對(duì)了方法，也沒那么累。核心就是一起學(xué)習(xí)，討論后端技術(shù)。這種方式會(huì)一直繼續(xù)下去。目前已經(jīng)有課程了，后續(xù)還會(huì)更新下去。 大家都知道，做我們開發(fā)這行的，最核心的競(jìng)爭(zhēng)力就是學(xué)習(xí)能力。技術(shù)一直在變化，框架一直在更新，學(xué)還是不學(xué)。 不學(xué)，你會(huì)落伍，學(xué)，太累了，根本學(xué)不過來。學(xué)習(xí)只要找對(duì)了方法，也沒那么累。 最好的學(xué)習(xí)方式那就是興趣...
摘要：的大數(shù)據(jù)策略目前，適用的大數(shù)據(jù)生態(tài)系統(tǒng)連接包括和支持和的多維分析數(shù)據(jù)庫(kù)可實(shí)時(shí)連接到數(shù)據(jù)源，或?qū)⑵湔{(diào)入內(nèi)存。面向業(yè)務(wù)用戶的大數(shù)據(jù)自助式可視化。應(yīng)對(duì)的是一些需要實(shí)施展現(xiàn)結(jié)果，比如銀行交易風(fēng)險(xiǎn)的流水分析，直接對(duì)接，，等大數(shù)據(jù)平臺(tái)。 市面上的BI工具形形色色，功能性能包裝得十分亮麗，但實(shí)際應(yīng)用中我們往往更關(guān)注的是樸實(shí)的技術(shù)特性和解決方案。對(duì)于大數(shù)據(jù)，未來的應(yīng)用趨勢(shì)不可抵擋，很多企業(yè)也正存在大數(shù)...
摘要：液體冷卻技術(shù)的優(yōu)勢(shì)在于能夠以更高的密度進(jìn)行部署，通過提高效率來降低總成本，并顯著減少占地面積。雖然液體冷卻的好處令人印象深刻，但其應(yīng)用障礙卻令人望而生畏。工智能的技術(shù)進(jìn)步，如今已經(jīng)從實(shí)驗(yàn)室的研究轉(zhuǎn)向真正的商業(yè)和消費(fèi)者應(yīng)用。由于人工智能應(yīng)用程序的計(jì)算量很大，因此許多IT硬件架構(gòu)師使用GPU作為核心處理器或輔助處理器。許多基于GPU的服務(wù)器，其散熱量是傳統(tǒng)服務(wù)器的兩倍，熱設(shè)計(jì)功率（TDP）達(dá)到了...
摘要：因?yàn)樵谥Ц哆^程中不能保證每一次操作都成功，所以還要引入一個(gè)日志表來做數(shù)據(jù)的一致性，保證用戶資金變動(dòng)與實(shí)際相符。雖然在數(shù)據(jù)設(shè)計(jì)中遇到一些復(fù)雜結(jié)構(gòu)的問題，比如和的問題。 [ 玩轉(zhuǎn) LeanCloud ] 開發(fā)者經(jīng)驗(yàn)分享： 作者：Davy 我們的產(chǎn)品叫「學(xué)海密探」，屬于在線教育行業(yè)，產(chǎn)品需要有支付功能，然而支付最蛋疼是什么？有人會(huì)說是支付寶和微信等支付接口的接入開發(fā)！沒錯(cuò)，但支付接口的開發(fā)算...
閱讀 2475·2019-08-30 15:52
閱讀 2265·2019-08-30 12:51
閱讀 2866·2019-08-29 18:41
閱讀 2849·2019-08-29 17:04
閱讀 844·2019-08-29 15:11
閱讀 1777·2019-08-28 18:02
閱讀 3632·2019-08-26 10:22
閱讀 2537·2019-08-26 10:12
