摘要：出現(xiàn)的問題筆者前段時(shí)間開發(fā)一個(gè)新項(xiàng)目的某個(gè)功能模塊要讀取老游戲中某個(gè)數(shù)據(jù)庫計(jì)作庫連續(xù)讀庫中的個(gè)集合相當(dāng)于的張表取數(shù)據(jù)在測試環(huán)境單次操作時(shí)是內(nèi)但是并發(fā)測試情況下比如內(nèi)個(gè)并發(fā)時(shí)讀取庫個(gè)集合的耗時(shí)能達(dá)到以上甚至且個(gè)并發(fā)請求幾乎同時(shí)完成但是在我本地

筆者前段時(shí)間開發(fā)一個(gè)新項(xiàng)目的某個(gè)功能模塊,要讀取老游戲中某個(gè)Mongo數(shù)據(jù)庫(計(jì)作A庫),連續(xù)讀A庫中的6個(gè)集合(相當(dāng)于MySQL的6張表)取數(shù)據(jù),在測試環(huán)境,單次操作時(shí)是10ms內(nèi),但是并發(fā)測試情況下,比如1s內(nèi)100個(gè)并發(fā)時(shí),讀取A庫6個(gè)集合的耗時(shí)能達(dá)到2s以上,甚至7,8s,且n個(gè)并發(fā)請求幾乎同時(shí)完成,但是在我本地環(huán)境,并發(fā)下,平均一次操作也在幾十ms到100多ms上下浮動(dòng),并發(fā)請求也比較正常

下面講述一下整個(gè)處理過程

雖然使用MongoDB的經(jīng)驗(yàn)不多,但是在我的認(rèn)知里,MongoDB的讀取性能不可能如此低,不然如何投入生產(chǎn)環(huán)境?

那么,到底是哪里出了問題呢?

對比本地環(huán)境和測試環(huán)境使用方式,發(fā)現(xiàn)一個(gè)區(qū)別,我本地環(huán)境在Docker中跑的Mongo容器實(shí)例,為了方便,并沒有設(shè)置用戶名和密碼,直接ip+端口號(hào)連接,而測試環(huán)境用了用戶名密碼,不管三七二十一,按照高中時(shí)候?qū)W的生物學(xué)中對照實(shí)驗(yàn)的思路,目前就只發(fā)現(xiàn)一個(gè)區(qū)別,先進(jìn)行驗(yàn)證

本地連接Mongo的url
127.0.0.1:27017

先按照網(wǎng)上的教程,給Admin數(shù)據(jù)庫建立一個(gè)管理員賬號(hào),擁有Mongo實(shí)例中讀寫任何一個(gè)db的權(quán)限

db.createUser({user:"root",pwd:"123456",roles:[{role:"userAdminAnyDatabase",db:"admin"}]})

使用賬號(hào)密碼后,無并發(fā)時(shí),仍然是ms級(jí)別,但是發(fā)現(xiàn),本地環(huán)境和測試環(huán)境一樣,并發(fā)時(shí),耗時(shí)達(dá)到數(shù)秒,且n個(gè)并發(fā)請求幾乎同時(shí)完成,好像某個(gè)操作導(dǎo)致阻塞,然后這個(gè)阻塞操作完成后,沒有阻塞只會(huì),并發(fā)讀取操作正常執(zhí)行,可以確定是Mongo數(shù)據(jù)庫的賬號(hào)管理相關(guān)問題

為啥賬號(hào)模塊會(huì)導(dǎo)致這么大的缺陷?

通過神器Google搜索,看了n篇博客,發(fā)現(xiàn)一篇12年的博客

該文作者在生產(chǎn)環(huán)境使用Mongo數(shù)據(jù)庫,有性能問題,其中一個(gè)關(guān)鍵點(diǎn)是,Mongo數(shù)據(jù)庫,如果有用戶名和密碼,在每次建立數(shù)據(jù)庫連接時(shí),都會(huì)驗(yàn)證用戶名密碼,建議在生產(chǎn)環(huán)境不要使用用戶名和密碼,通過禁止外網(wǎng)訪問,通過內(nèi)網(wǎng)ip以及限制ip的方式,訪問mongo數(shù)據(jù)庫

由于線上老項(xiàng)目是lua寫的,公司已經(jīng)一年多未進(jìn)行代碼維護(hù),且準(zhǔn)備后面新項(xiàng)目上線后,直接下線老項(xiàng)目,筆者以及公司其他后端,都不懂lua,為了避免導(dǎo)致不可預(yù)料的問題,同時(shí),在我看來,用戶名和密碼,對于數(shù)據(jù)庫而言是最重要的安全模塊,全球那么多公司在使用,就算賬號(hào)驗(yàn)證有一定的性能損耗,但是也不可能有這么大的問題,應(yīng)該還是我自己使用方面的問題,繼續(xù)深入尋找原因

通過請教一位同事,公司另一個(gè)基礎(chǔ)服務(wù)(計(jì)作B服務(wù)吧)在生產(chǎn)環(huán)境也用了MongoDB,且流量也很大,并沒有問題,通過對比

我的方式:
user:[email protected]:27017/admin
然后在代碼中通過use,切換到baby庫

B服務(wù)的方式:
針對baby數(shù)據(jù)庫建立一個(gè)賬號(hào),由baby庫授權(quán)
user:[email protected]:27017/baby?authSource=baby&maxPoolSize=50

區(qū)別在于我是跳轉(zhuǎn)到baby庫,而正常環(huán)境下是使用該數(shù)據(jù)庫下的用戶

說明數(shù)據(jù)庫授權(quán)耗時(shí)以及數(shù)據(jù)庫切換也比較耗時(shí),為啥會(huì)耗時(shí),看到一篇博客講到了Mongo的賬號(hào)授權(quán)原理,知道了建立連接數(shù)據(jù)庫授權(quán)時(shí)會(huì)導(dǎo)致庫級(jí)鎖(即連接a在使用時(shí),連接b進(jìn)行授權(quán),也會(huì)導(dǎo)致baby庫鎖定,連接a被阻塞)

于是接著本地也適用B服務(wù)一樣的方式,通過baby庫下建立user賬號(hào),直連的方式連接,本地環(huán)境耗時(shí)正常,并發(fā)下讀取6個(gè)集合,在100ms以內(nèi),屬于正常性能,但是發(fā)到測試環(huán)境,并發(fā)下雖然耗時(shí)減少了,相對于之前的8s,現(xiàn)在依然有1s多的延遲

連接數(shù)據(jù)庫方式一樣,但是耗時(shí)差別很大,經(jīng)過上一步知道了耗時(shí)是因?yàn)閿?shù)據(jù)庫鎖機(jī)制導(dǎo)致的問題,后面在Google上搜Mongo鎖機(jī)制,在知乎上看到了一個(gè)回答

mongodb 最初是全局鎖，后來庫鎖，接著3.0進(jìn)化到表鎖了... 現(xiàn)在使用 WiredTiger 可以實(shí)現(xiàn)文檔鎖...

對比了測試環(huán)境和本地環(huán)境的版本,本地是最新的,已經(jīng)是3.6版本,測試環(huán)境還是2.6版本,屬于庫鎖

到此,可以知道問題所在了,MongoDB賬號(hào)授權(quán)機(jī)制以及數(shù)據(jù)庫鎖機(jī)制

感興趣的客觀可以搜索MongoDB鎖機(jī)制相關(guān)博客,網(wǎng)上文章很多,我就不在此啰嗦了

Mongo數(shù)據(jù)庫,在生產(chǎn)環(huán)境,盡量通過限制內(nèi)網(wǎng)ip才可以訪問的方式保證安全,防止攻擊

其次,不要通過admin管理員用戶連接數(shù)據(jù)庫,該賬號(hào)只是做為管理員使用,而不應(yīng)該作為生產(chǎn)環(huán)境使用,MongoDB的思想是賬號(hào)和數(shù)據(jù)庫綁定,而不是實(shí)例,MySQL是一個(gè)MySQL實(shí)例對應(yīng)賬號(hào),不針對某db

盡量使用3.X的新版本MongoDB,數(shù)據(jù)庫鎖已經(jīng)完善

以上只是我個(gè)人解決這個(gè)問題的全過程,博客寫的不夠思路清晰,過去了半個(gè)月,細(xì)節(jié)也記得不是很清楚了了,希望能給技術(shù)圈有所貢獻(xiàn),謝謝支持