本文的主要內容**於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在重啟後並不需要進行快取重建與預熱。
下面是幾點比較實用的知識：
參考源：blog.mongodb.org
不可忽略的資料庫快取重建
引用 本文的主要內容 於mongodb官方部落格，由nosqlfan補充說明，本文對傳統的分布式cache系統進行了分析，指出了其在快取重建中會對資料庫產生巨大壓力的問題。並分析了mongodb的mmap方案是如何規避這一問題的。如下圖的架構，在資料庫前端加上分布式的cache 比如我們常用的mem...
設計中不可忽略的產品狀態
在產品的設計過程中，設計師總喜歡把圖做的很漂亮，在虛擬頁面的內容時，使用漂亮的，把內容安排的恰到好處。但是當產出介面demo時，這個頁面可能是個空內容的頁面，也可能內容很多，導致布局錯位。所以在設計介面時，一定不能忽視空狀態 內容過多等極限狀態。這些狀態也許只會在初次使用時遇到，也許只會有很小一部分...
SEO不可忽略的幾個優化細節
隨著搜尋引擎演算法的更新和改進，優化也變得愈發的精細了，許多的站長往往會覺得為什麼自己在優化中付出的努力高於其他人而且很多地方都比別人要做得不比別人差，可是取得的結果卻並沒有別人好，甚至是比他們差很多。之所以出現這樣的結果通常是由於大家在細節上有所疏忽不重視而造成的，在seo行業，細節決定成敗這個說...