1. 程式人生 > >如何利用MongoDB打造TOP榜小程式

如何利用MongoDB打造TOP榜小程式

歡迎大家前往騰訊雲+社群,獲取更多騰訊海量技術實踐乾貨哦~

本文由騰訊雲資料庫 TencentDB發表於雲+社群專欄

今天我分享的主題內容大概是兩部分,最主要的還是小遊戲和小程式,第一部分就是跟大家分享下我們在現網運營中服務小遊戲以及爆款小遊戲積累的經驗。在現網運維中我們做了一些改動,幫助爆款小遊戲能夠穩定執行。第二部分我們推出了一套新的解決方案,適合小白開發者,適合初創公司,可以在微信開發小程式的同時,能夠使用騰訊雲的資源,享受騰訊雲的各種服務。

img

先講第一部分的內容,剛才鄒鵬最後講的一段的時候,一直有一個圖片,那個圖片就是各種資料庫的排名,可能大家沒有注意到,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毫秒左右,非常快。以上是我們第二個優化。

img

業務最開始上線的時候其實並不知道後期量級能達到多少,假設開發人員在最開始的時候申請比較大的例項的話,其實會被運維挑戰的。但是假如用分片叢集的話,就會避免這個問題。最開始的時候設定很小的,買一個很小的分片,後面你的業務量大起來之後,再水平擴分片。只需要指定分片的Key,就會把資料分到不同的片裡面去,自動做均衡,業務無感知。

img

庫表回檔,在遊戲運維過程中比較痛苦的一件事就需要回檔。確實很痛苦,有時候我感覺有些使用者回檔過程中非常著急,一旦回檔應該是發生了比較嚴重的事,要回檔到之前的時間段。因為程式是避免不了有Bug的,或者遊戲在上線過程中有一個Leader手抖,發了很多道具,可能造成很多人民幣的損失,這個時候就要進行回檔。但是僅僅是某個庫表進行回檔,不需要整例項回檔,針對這種情況,我們支援庫表回檔,對運維人員是非常nice的功能。

img

我的第二部分內容就是針對小遊戲和小程式的一種解決方案。小程式開發和小遊戲開發特別是小遊戲會遇到一個問題,使用本地快取30-40M完全不夠,如何把小程式賦能到雲,我們提供了方案,不需要到騰訊買CVM、資料庫、函式,只需要在小程式開發IDE上點選控制檯上的按鈕,開發者只需要關注業務邏輯的實現,後端的伺服器的運維知識都不需要再去了解。小遊戲和小程式的特點就是短平快,快速上線,迭代快法,強佔市場,通過一些道具和廣告迅速變現,生命週期不長。

img

我們這個解決方案在服務層有資料庫的管理、檔案的管理、函式的管理,後面還會加一些日誌、觸發器的服務,底層服務有騰訊雲MongoDB、雲函式這一套。也就是說剛才我們在服務現網其他遊戲中的運維經驗的累計都會應用到這個解決方案裡面,所以說大家可以放心使用。

開發過程中會有多個環境,開發環境、測試環境、生產環境,在雲上開通這套服務之後我們預設會包含多個環境,環境之間是相互隔離的。

這種方案特別適合個人開發者、初創團隊,對於成熟團隊需要上一些專案的話,可以立即使用。以下是我們的控臺,有三個功能,可以建立集合,我們增加了匯入和匯出功能,可以把其他地方的資料導到這裡面讓你的小程式直接執行。第二就是索引,我們把索引功能優先開出來了,預設給_id欄位加了索引,使用者也可以自己增加單列索引和複合索引。另外,許可權管理這裡也非常精細。

我今天的分享差不多是這樣。更多資料庫前沿技術可關注 我們公眾號:騰訊雲資料庫CDB

img

Q&A:

Q:老師,您好,您剛剛講的關於監控資料,我想問的是關於小程式會讓使用者看到日誌以及監控資料嗎?你們有提供報警機制嗎?

A:我覺得你應該是深入思考這件事了,確實是,監控和日誌很重要,日誌很快會包到解決方案裡面,用的是ES。現在監控指標跟MongoDB公有云的資料是一樣的。告警我們做了策略,會對關鍵指標的告警系統進行預值自動設定,自動告警,使用者自定義告警在短期內還沒有提供。

Q: 您好,老師,今天下午辛苦了。我曾經不太瞭解MongoDB,我聽說MongoDB有一個安全的事件,應該在一年以內,但具體時間不清楚,我想了解一下,比如說雲上Mongo的安全的這塊,你們是怎麼做的?

A:安全有兩點,第一點是網路,我們會有在前面加了安全組,這樣對訪問來源IP進行了第一層過濾,安全組,使用者可以自己設定。第二我們加了VPC網路,在自己虛擬機器同一個網路類的CVM才能訪問我們的Mongo,這樣就做了網路隔離。第二方面我們有資料加密,我們現在做的是儲存型加密,這個加密功能是使用者在購買的時候可以選擇的,所以說用我們騰訊雲MongoDB的安全是完全可以放心的,但是你自建的話可能就沒有這麼。

Q:您剛說的VBC,如果自建的話,咱們的網路就是獨立的。

A:自建的話,VBC可以做到,但是資料層的加密是做不到的。

相關閱讀
【每日課程推薦】機器學習實戰!快速入門線上廣告業務及CTR相應知識

此文已由作者授權騰訊雲+社群釋出,更多原文請點選

搜尋關注公眾號「雲加社群」,第一時間獲取技術乾貨,關注後回覆1024 送你一份技術課程大禮包!

海量技術實踐經驗,盡在雲加社群