歡迎大家前往 "騰訊雲+社區" ，獲取更多騰訊海量技術實踐乾貨哦~ 本文由 "騰訊雲資料庫 TencentDB" 發表於 "雲+社區專欄" 今天我分享的主題內容大概是兩部分，最主要的還是小游戲和小程式，第一部分就是跟大家分享下我們在現網運營中服務小游戲以及爆款小游戲積累的經驗。在現網運維中我們做了一 ...
歡迎大家前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~
本文由騰訊雲資料庫 TencentDB發表於雲+社區專欄
今天我分享的主題內容大概是兩部分，最主要的還是小游戲和小程式，第一部分就是跟大家分享下我們在現網運營中服務小游戲以及爆款小游戲積累的經驗。在現網運維中我們做了一些改動，幫助爆款小游戲能夠穩定運行。第二部分我們推出了一套新的解決方案，適合小白開發者，適合初創公司，可以在微信開發小程式的同時，能夠使用騰訊雲的資源，享受騰訊雲的各種服務。
先講第一部分的內容，剛纔鄒鵬最後講的一段的時候，一直有一個圖片，那個圖片就是各種資料庫的排名，可能大家沒有註意到，MongoDB的排名其實已經是第五名，再說一下MongoDB為什麼適合游戲開發場景。我們知道游戲開發中一個最主要的特點是需求變化非常快的，因為在游戲不同的階段會加入一些新的元素黏住用戶，例如道具，在游戲上線的不同階段加不同道具，這種用傳統的關係型資料庫不免對錶進行結構修改的DDL的操作，可能有些開發者說不需要，之前做的就是把所有的欄位打包成一個欄位塞進一個庫表就可以了。使用MongoDB不需要改變表結構，對開發者是非常Nice的。另外，大多數游戲會添加社交元素增強用戶的活躍度，黏住用戶。我們提供了地理位置索引以及配套的API，不需要在業務層做操作，資料庫層已經原生支持了。海量數據的支持，我們提供了分片的功能，其實數據最開始，在業務上線最開始階段，並不知道到底將來是什麼樣的量級。使用關係型資料庫的話，後期避免不了進行分庫分表，擴容，MongoDB這邊提供了分片集群，可以在不影響業務的同時進行水平的擴容，這個對運維來說是非常好的解決方案。
運營分析，現在是大數據時代，每個業務都會根據數據分析的結果支持運營策略，我們是原生支持MapReduce的，開發者可以直接使用。還有一點非常重要，假如你是小程式開發的話，用JS語言寫，存在javascript技術棧MEAN和MERN，MongoDB和Nodejs兩者是伴隨成長起來的。總之，MongoDB特別適合游戲開發場景。
我想問一下現在在座的有沒有用我們騰訊雲MongoDB的？或者是有沒有用MongoDB的？自建也可以。你們用MongoDB存什麼數據？（目前搜集用戶行為日誌）是自建的嗎？（對，本來想用雲上，後來發現自建會便宜一點）一主兩從還是一主一從？（做副本集，三個部分，沒有固定說哪個是主）實例多大？（現在幾十G的數據量）你們買的CVM是多大？（500G空間，我們前期使用起來，現在一個方向還不太明確，就是一個試探，我在之前用的都是阿裡的比較多，騰訊是今年才開始接觸）我大概瞭解了，所以說我覺得今天能站在這分享，跟這麼多用戶見面，對我個人來說是非常高興的一件事，至少我知道大家現在怎麼使用以及有沒有用，不用我一一拜訪了。
小游戲的調用棧，很多開發者都非常清楚，我只需要簡單的帶過，一般會在前面加負載均衡，然後通過虛擬機搭建伺服器，後面連資料庫。
我剛纔跟大家提了我們其實在現網服務過很多爆款小游戲了，最主要的一個目的就是能夠讓客戶的游戲穩定運行，我們在服務他們的過程中，累積了一些運維經驗，做了一些連接參數的調優，幫客戶實現實例價值的最大化。
首先跟大家簡單分享一下MongoDB的連接模型，分兩部分，第一部分是Mongos對客戶端的連接，第二是Mongos對後端的連接，第一部分連接採用的是非常古老的方式，叫one-Thread-per-connection，每個連接分配一個線程，每個線程棧1MB記憶體，1000個連接是1G記憶體，所以，MongoDB對連接是非常敏感的。對後端連接的模型就是每個Mongos會綁定一個Worker池，假如你有三分片，每個分片是一主兩從，那就是9個Mongod，每個worker就會有9個連接。
這裡有一個參數，如果這個參數設計的不合理，業務體量比較高的情況下，後面連接池子的線程是不夠用的，就會進行頻繁的線程調度和切換，因為線程的切換和調度的開銷是比較大的，所以運維人員比較關心的就是minConnection這個參數，這個參數我們是單獨提出來能夠給運維人員直接修改的，這個參數的設置有一個公式，這個公式就是你需要根據，比如當前TPS為1000，每個連接要求處理10毫秒，2個分片,minConnection=1000/2/(1000/10)。則第二個參數也是運維人員比較關心的，第二就是refreshRequirement，就是每個業務會有一個估算的連接峰值，那麼refreshRequirement設置要超過5分鐘才行。以上是我們對MongoDB連接模型的優化。
第二個我們服務現網很多小游戲時遇到的慢查詢問題。很多用戶比較瞭解MongoDB的話，因為是一主兩從，就會為了減少主的壓力，就設置把讀請求打到從，從可以同步數據，也可以接收讀請求，主就做接收寫請求，這是理想的方案，但是我們服務用戶過程中發現這個方案也會帶來問題，因為從3.2版本，引擎就預設是WT。WT引擎有一個操作就是從在同步數據的時候會加一個全局鎖，這個鎖會把所有的讀請求都鎖住，這樣的話慢查詢就可能會變多，基於這個問題，我們這邊是搞了一個專利，這個專利就是基於快照的讀的一種方案，就是當你進行從讀的時候，此時讓你讀快照，同步數據完成之後，所有讀請求正常，快照被清掉。最左邊的圖是另外一個解決方案，這種解決方案就是我們提供了一種只讀實例，在主實例上掛只讀實例，主實例負責接收讀寫請求，其他業務模塊只需要把所有的連接請求打到只讀就可以了。這兩種解決方案在一般情況下的優勢不是非常明顯，但是當你的實例Primary寫入壓力非常大的情況下，效果是非常明顯的。最後面有一張圖，藍色部分是源生的Mongo，紅色的部分是我們基於讀快照的方式的一個性能，X軸是寫入大小，Y軸就是從庫讀請求的延時，我們發現在源生的Mongo中最大的讀延時能達到85毫秒左右。用我們的解決方案的話，在10毫秒左右，非常快。以上是我們第二個優化。
業務最開始上線的時候其實並不知道後期量級能達到多少，假設開發人員在最開始的時候申請比較大的實例的話，其實會被運維挑戰的。但是假如用分片集群的話，就會避免這個問題。最開始的時候設置很小的，買一個很小的分片，後面你的業務量大起來之後，再水平擴分片。只需要指定分片的Key，就會把數據分到不同的片裡面去，自動做均衡，業務無感知。
庫表回檔，在游戲運維過程中比較痛苦的一件事就需要回檔。確實很痛苦，有時候我感覺有些用戶回檔過程中非常著急，一旦回檔應該是發生了比較嚴重的事，要回檔到之前的時間段。因為程式是避免不了有Bug的，或者游戲在上線過程中有一個Leader手抖，發了很多道具，可能造成很多人民幣的損失，這個時候就要進行回檔。但是僅僅是某個庫表進行回檔，不需要整實例回檔，針對這種情況，我們支持庫表回檔，對運維人員是非常nice的功能。
我的第二部分內容就是針對小游戲和小程式的一種解決方案。小程式開發和小游戲開發特別是小游戲會遇到一個問題，使用本地緩存30-40M完全不夠，如何把小程式賦能到雲，我們提供了方案，不需要到騰訊買CVM、資料庫、函數，只需要在小程式開發IDE上點擊控制臺上的按鈕，開發者只需要關註業務邏輯的實現，後端的伺服器的運維知識都不需要再去瞭解。小游戲和小程式的特點就是短平快，快速上線，迭代快法，強占市場，通過一些道具和廣告迅速變現，生命周期不長。
我們這個解決方案在服務層有資料庫的管理、文件的管理、函數的管理，後面還會加一些日誌、觸發器的服務，底層服務有騰訊雲MongoDB、雲函數這一套。也就是說剛纔我們在服務現網其他游戲中的運維經驗的累計都會應用到這個解決方案裡面，所以說大家可以放心使用。
開發過程中會有多個環境，開發環境、測試環境、生產環境，在雲上開通這套服務之後我們預設會包含多個環境，環境之間是相互隔離的。
這種方案特別適合個人開發者、初創團隊，對於成熟團隊需要上一些項目的話，可以立即使用。以下是我們的控台，有三個功能，可以創建集合，我們增加了導入和導出功能，可以把其他地方的數據導到這裡面讓你的小程式直接運行。第二就是索引，我們把索引功能優先開出來了，預設給_id欄位加了索引，用戶也可以自己增加單列索引和複合索引。另外，許可權管理這裡也非常精細。
我今天的分享差不多是這樣。更多資料庫前沿技術可關註 我們公眾號：騰訊雲資料庫CDB
Q&A：
Q：老師，您好，您剛剛講的關於監控數據，我想問的是關於小程式會讓用戶看到日誌以及監控數據嗎？你們有提供報警機制嗎？
A：我覺得你應該是深入思考這件事了，確實是，監控和日誌很重要，日誌很快會包到解決方案裡面，用的是ES。現在監控指標跟MongoDB公有雲的數據是一樣的。告警我們做了策略，會對關鍵指標的告警系統進行預值自動設定，自動告警，用戶自定義告警在短期內還沒有提供。
Q： 您好，老師，今天下午辛苦了。我曾經不太瞭解MongoDB，我聽說MongoDB有一個安全的事件，應該在一年以內，但具體時間不清楚，我想瞭解一下，比如說雲上Mongo的安全的這塊，你們是怎麼做的？
A：安全有兩點，第一點是網路，我們會有在前面加了安全組，這樣對訪問來源IP進行了第一層過濾，安全組，用戶可以自己設置。第二我們加了VPC網路，在自己虛擬機同一個網路類的CVM才能訪問我們的Mongo，這樣就做了網路隔離。第二方面我們有數據加密，我們現在做的是存儲型加密，這個加密功能是用戶在購買的時候可以選擇的，所以說用我們騰訊雲MongoDB的安全是完全可以放心的，但是你自建的話可能就沒有這麼。
Q：您剛說的VBC，如果自建的話，咱們的網路就是獨立的。
A：自建的話，VBC可以做到，但是數據層的加密是做不到的。
此文已由作者授權騰訊雲+社區發佈，更多原文請點擊
搜索關註公眾號「雲加社區」，第一時間獲取技術乾貨，關註後回覆1024 送你一份技術課程大禮包！
海量技術實踐經驗，盡在雲加社區！
