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

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

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

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

　　我們經常看到一些網站掛掉后又恢復，恢復后又掛掉，如此反復幾次才能真正恢復，原因就在于其第一次Cache倒了，數據庫無法承受相應的讀壓力，在緩存重建了一小部分后被壓死。相當于數據庫每重啟一次，可以恢復部分緩存，直到緩存的非命中率到達數據庫可承受的壓力時，才能夠真正恢復服務。

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

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

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

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

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

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

　　參考源：blog.mongodb.org