本文的主要內容來源於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 來爲其爭取更多的物理內存。
