瘋狂了！當遊戲愛上MongoDB會怎麼樣？？？

導讀	前端時間魔獸這個電影我相信大家都看過了哈，作為一個碼農，有時候我也會去思考魔獸世界這個遊戲背後他的一些設計和實現，比如他用什麼資料庫。當然真正用什麼資料庫這個我是不確定的，我們今天的主題是當遊戲愛上MongoDB，所以我們只聊遊戲如果採用MongoDB作為資料庫有哪些好處。

我們知道，遊戲的一個特點是需求變化快，為了保持玩家一直有新鮮感，需要不停的往遊戲中加入新的元素。就拿一些MMO遊戲的裝備（道具）系統為例，假如使用傳統的關係型資料庫來存放這些資料，可能會面臨需要經常做表結構修改這樣的DDL操作。那如果採用MongoDB的話就不會有這個問題，schema-free的特性可以支援一個表（集合）內包含不同結構的文件。此外，MongoDB直接使用JSON格式進行資料互動，這也是最接近物件模型的，對開發人員來說非常友好。關於如何使用MongoDB進行資料建模可以參考TJ寫的MongoDB進階模式設計。

現在很多遊戲都走遊戲免費道具收費的模式，有很多類似道具自動過期的功能，這可以透過MongoDB的TTL索引來輕而易舉的實現。同樣，現在很多遊戲使用地理位置來作為社交系統的一部分，比如附近玩家這樣的功能。這也可以直接利用MongoDB的地理位置索引來做。MongoDB原生支援了這些功能，可以說非常方便。

以前玩魔獸世界的時候，每個禮拜二都要來一次停服維護。當時大家也習慣了，畢竟魔獸世界還是玩點卡的，遊戲時間都是自己花錢買的。但對於現在的免費遊戲來說，經常停服，可能玩家都會接受不了。對那些日流水好幾位數字的遊戲公司來說，時間就是金錢，停服維護可能就有種自己在不停燒錢的感覺。所以現在都要追求服務高可用，儘可能減少停服時間。資料庫服務通常也是整個遊戲服務中的一個重要環節。MongoDB的副本集是一個相當成熟的高可用架構，它透過一主多備結構保證服務的可用性，當主當機後還存活的備會自動選舉出新的主。


阿里雲資料庫MongoDB在MongoDB自身高可用架構下做了進一步增強。採用一主一備一隱藏節點的經典3節點配置，對外暴露兩個VIP提供使用者訪問，在某個節點當機時自動進行VIP切換，保證使用者始終有2個節點可用。需要注意的是，這必須是使用者正確配置成副本集訪問模式時才生效。

說完高可用，我們來說說高可擴充套件方面。同樣還是魔獸世界，想必很多早期玩家都體驗過排隊，之所以要排隊，主要是因為服務能力不夠導致。當然，這通常和資料庫無關，不過，一個好的架構師是不會允許有某個環節出現明顯的瓶頸的。MongoDB由於其資料相對獨立的特性，相比於關係型資料庫，較容易進行水平擴充套件。其Sharding架構已在很多生產環境中久經驗證，業內有些公司對其進一步最佳化後已在管理上百PB的資料。對於運維人員來說也是相當友好，動態擴容和負載均衡都是自動進行的，使用者只需要選一個好的shard key即可。

運營遊戲有時候會面臨不得不對遊戲進行回檔這樣的痛苦選擇。因為程式不可避免會有bug的存在，如果有某個bug被惡意利用，亦或者是人皆會犯錯誤，某個GM不小心手抖發了大量RMB道具，都可能導致較大的經濟損失出現。如果遊戲不是很完善，沒有一個更好的解決方案的情況下，這時候可能就要考慮對遊戲進行回檔了。對於資料庫資料的回檔來說，MongoDB提供了一個延遲副本集節點的設定來解決這個問題。即，將某個節點配置成落後於最新資料一定的時間量。

當然，這還是很粗粒度的，如果要精 確回檔到延遲時間內或者更早的時間點，甚至是任意時間點，就還要在備份恢復這塊上做更多的工作。阿里雲MongoDB近期會推出任意時間點恢復的功能，以滿足包括這個場景在內的備份恢復需求，敬請關注。

現在是大資料時代，透過資料分析輔助運營決策是必不可少的。在資料分析方面，MongoDB提供了Aggregation pipeline和Map-Reduce這兩個強大的功能。其中Aggregation pipeline使用管道處理模型，提供了過濾、分組、排序等豐富的操作支援，具有較簡單的操作性兼顧較好的效能，而Map-Reduce則可以使用JavaScript進行自定義處理，在靈活性上更勝一籌。

綜上所述，MongoDB有如此多的適合於遊戲開發場景的特性，還等什麼呢？

原文來自：