瘋狂了！當遊戲愛上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有如此多的適合於遊戲開發場景的特性，還等什麼呢？

本文地址： http://www.linuxprobe.com/games-love-mongodb.html