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