本文的主要內(nèi)容來源于MongoDB官方博客，由NoSQLFan補充說明，本文對傳統(tǒng)的分布式Cache系統(tǒng)進(jìn)行了分析，指出了其在緩存重建中會對數(shù)據(jù)庫產(chǎn)生巨大壓力的問題。并分析了MongoDB的mmap方案是如何規(guī)避這一問題的。

　　如下圖的架構(gòu)，在數(shù)據(jù)庫前端加上分布式的Cache（比如我們常用的Memcached），讓客戶端在訪問時先查找Cache，Cache不命中再讀數(shù)據(jù)庫并將結(jié)構(gòu)緩存在Cache中。這是目前比較常用的一種分擔(dān)讀壓力的方法。

　　但是這個方法存在一個問題，如果前端的Cache掛掉，或者比較極端的整個機房斷電了，那么在機器重啟后，原來Cache機器在內(nèi)存中的緩存會全部清空，在客戶端訪問過程中，會百分之百的不命中，這樣數(shù)據(jù)庫會在瞬間接受巨大的讀壓力。

　　試想如果一個64GB的緩存失效了，在其重建時，假設(shè)與數(shù)據(jù)庫連接的千兆網(wǎng)卡，假設(shè)其以極限速度100M每秒從數(shù)據(jù)庫取數(shù)據(jù)過來重建緩存，那么也需要10分鐘才能建完。更何況這是理想情況，對于客戶端觸發(fā)式的隨機緩存重建，可能會花掉更長的時間。這還是在數(shù)據(jù)庫能提供100M每秒的數(shù)據(jù)讀請求的前提下。

　　我們經(jīng)?？吹揭恍┚W(wǎng)站掛掉后又恢復(fù)，恢復(fù)后又掛掉，如此反復(fù)幾次才能真正恢復(fù)，原因就在于其第一次Cache倒了，數(shù)據(jù)庫無法承受相應(yīng)的讀壓力，在緩存重建了一小部分后被壓死。相當(dāng)于數(shù)據(jù)庫每重啟一次，可以恢復(fù)部分緩存，直到緩存的非命中率到達(dá)數(shù)據(jù)庫可承受的壓力時，才能夠真正恢復(fù)服務(wù)。

　　這個問題可以用一些可以提供持久化功能的緩存來實現(xiàn)，比如Redis，在未開啟aof的情況下，其定期dump出來的rdb文件出能自動恢復(fù)出絕大部分?jǐn)?shù)據(jù)，當(dāng)然，在有的時候這可能導(dǎo)致緩存和數(shù)據(jù)庫數(shù)據(jù)不一致的情況，需要根據(jù)應(yīng)用場景選擇性的使用。

　　上面是對分布式Cache的問題，而對于很多數(shù)據(jù)庫存儲，實際上也幾乎都是將熱數(shù)據(jù)盡量放在內(nèi)存中的。但很多數(shù)據(jù)庫在實現(xiàn)上是自己在內(nèi)存中實現(xiàn)了Cache機制，這樣在數(shù)據(jù)庫重啟（非操作系統(tǒng)重啟）時，這些Cache可能也就隨之被清空了，對于數(shù)據(jù)庫來說，也需要重建緩存，而數(shù)據(jù)庫這時所有的操作可能都落在磁盤IO上，帶來了同樣的問題。

　　而MongoDB與上面的方式不太一樣，MongoDB采用mmap來將數(shù)據(jù)文件映射到內(nèi)存中，所以當(dāng)MongoDB重啟時，這些映射的內(nèi)存并不會清掉，因為它們是由操作系統(tǒng)維護(hù)的（所以當(dāng)操作系統(tǒng)重啟時，MongoDB才會有相同問題）。相對于其它一些自己維護(hù)Cache的數(shù)據(jù)庫，MongoDB在重啟后并不需要進(jìn)行緩存重建與預(yù)熱。

　　另外，新浪微博的timyang也曾經(jīng)提出過一種緩存重建加鎖的方式，也能部分解決此問題。簡單來說就是緩存重建時，當(dāng)多個客戶端對同一個緩存數(shù)據(jù)發(fā)起請求時，會在客戶端采用加鎖等待的方式，對同一個Cache的重建需要獲取到相應(yīng)的鎖才行，只有一個客戶端能拿到鎖，并且只有拿到鎖的客戶端才能訪問數(shù)據(jù)庫重建緩存，其它的客戶端都需要等待這個拿到鎖的客戶端重建好緩存后直接讀緩存，其結(jié)果是對同一個緩存數(shù)據(jù)，只進(jìn)行一次數(shù)據(jù)庫重建訪問。但是如果訪問分散比較嚴(yán)重，還是會瞬間對數(shù)據(jù)庫造成非常大的壓力。

　　下面是幾點比較實用的知識：

• 無論使用哪個存儲，都最好先搞清楚其緩存重建的過程，如果一次重啟就可能導(dǎo)致數(shù)據(jù)庫崩潰，還是小心為好，最好把重啟時間選在訪問量比較小的時候。
• 重啟MongoDB不會導(dǎo)致MongoDB的緩存失效（除非重啟服務(wù)器）
• 當(dāng)你重新mount磁盤時，文件系統(tǒng)的緩存會失效，這和重啟機器時一樣，MongoDB也無法避免
• 一個使用MongoDB的小技巧，當(dāng)MongoDB服務(wù)器剛啟動時，你可以將其所有文件copy到/dev/null中，這會觸發(fā)操作系統(tǒng)對這些文件的讀操作，從而在內(nèi)存允許的條件下，會將盡可能多的MongoDB數(shù)據(jù)文件映射到物理內(nèi)存中。當(dāng)然，如果在MongoDB運行過程中，你能夠判斷哪些文件保存的數(shù)據(jù)是熱數(shù)據(jù)，也可以將這些文件copy到/dev/null 來為其爭取更多的物理內(nèi)存。

　　參考源：blog.mongodb.org

it知識庫：不可忽略的數(shù)據(jù)庫緩存重建，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。