轉(zhuǎn)載自：http://www.jzxue.com/shujuku/shujukuzonghe/201005/19-3807.html
先說說自己對Memcache和Mongodb的一些看法，主要是拋磚引玉了，希望看到大家的意見和補充。
Memcache
Memcache的優(yōu)勢我覺得總結(jié)下來主要體現(xiàn)在：
1） 分布式。可以由10臺擁有4G內(nèi)存的機器，構(gòu)成一個40G的內(nèi)存池，如果覺得還不夠大可以增加機器，這樣一個大的內(nèi)存池，完全可以把大部分熱點業(yè)務(wù)數(shù)據(jù)保存進去，由內(nèi)存來阻擋大部分對數(shù)據(jù)庫讀的請求，對數(shù)據(jù)庫釋放可觀的壓力。
2） 單點。如果Web服務(wù)器或App服務(wù)器做負載均衡的話，在各自內(nèi)存中保存的緩存可能各不相同，如果數(shù)據(jù)需要同步的話，比較麻煩（各自自己過期，還是分發(fā)數(shù)據(jù)同步？），即使數(shù)據(jù)并不需要同步，用戶也可能因為數(shù)據(jù)的不一致而產(chǎn)生用戶體驗上的不友好。
3） 性能強。不用懷疑和數(shù)據(jù)庫相比確實是，根源上還是內(nèi)存的讀寫和磁盤讀寫效率上幾個數(shù)量級的差距。有的時候我們在抱怨數(shù)據(jù)庫讀寫太差的情況下可以看看磁盤的IO，如果確實是瓶頸的話裝啥強勁的數(shù)據(jù)庫估計也檔不了，強不強無非是這個數(shù)據(jù)庫多少充分的利用了內(nèi)存。
但是也不太建議在任何情況下使用Memcache替代任何緩存：
1） 如果Value特別大，不太適合。因為在默認編譯下Memcache只支持1M的Value（Key的限制到不是最大的問題）。其實從實踐的角度來說也不建議把非常大的數(shù)據(jù)保存在Memcache中，因為有序列化反序列化的過程，別小看它消耗的CPU。說到這個就要提一下，我一直覺得Memcache適合面向輸出的內(nèi)容緩存，而不是面向處理的數(shù)據(jù)緩存，也就是不太適合把大塊數(shù)據(jù)放進去拿出來處理之后再放進去，而是適合拿出來就直接給輸出了，或是拿出來不需要處理直接用。
2） 如果不允許過期，不太適合。Memcache在默認情況下最大30天過期，而且在內(nèi)存達到使用限制后它也會回收最少使用的數(shù)據(jù)。因此，如果我們要把它當(dāng)作static變量的話就要考慮到這個問題，必須有重新初始化數(shù)據(jù)的過程。其實應(yīng)該這么想，既然是緩存就是拿到了存起來，如果沒有必定有一個重新獲取重新緩存的過程，而不是想著它永遠存在。
在使用Memcache的過程中當(dāng)然也會有一些問題或者說最佳實踐：
1） 清除部分?jǐn)?shù)據(jù)的問題。Memcache只是一個Key/Value的池，一個公共汽車誰都可以上。我覺得對于類似的公共資源，如果用的人都按照自己的規(guī)則來的話很容易出現(xiàn)問題。因此，最好在Key值的規(guī)范上上使用類似命名空間的概念， 每一個用戶都能很明確的知道某一塊功能的Key的范圍，或者說前綴。帶來的好處是我們?nèi)绻枰蹇盏脑捒梢愿鶕?jù)這個規(guī)范找到我們自己的一批Key然后再去清空，而不是清空所有的。當(dāng)然有人是采用版本升級的概念，老的Key就讓它過去吧，到時候自然會清空，這也是一種辦法。不過Key有規(guī)范總是有好處的，在統(tǒng)計上也方便一點。
2） Value的組織問題。也就是說我們存的數(shù)據(jù)的粒度，比如要保存一個列表，是一個保存在一個鍵值還是統(tǒng)一保存為一個鍵值，這取決于業(yè)務(wù)。如果粒度很小的話最好是在獲取的時候能批量獲取，在保存的時候也能批量保存。對于跨網(wǎng)絡(luò)的調(diào)用次數(shù)越少越好，可以想一下，如果一個頁面需要輸出100行數(shù)據(jù)，每一個數(shù)據(jù)都需要獲取一次，一個頁面進行上百次連接這個性能會不會成問題。
那么Memcache主要用在哪些功能上呢？
其實我覺得平時能想到在內(nèi)存中做緩存的地方我們都可以考慮下是不是可以去適用分布式緩存，但是主要的用途還是用來在前端或中部擋一下讀的需求來釋放Web服務(wù)器App服務(wù)器以及DB的壓力。
Mongodb
Mongodb是一款比較優(yōu)良的非關(guān)系型數(shù)據(jù)庫的文檔型的數(shù)據(jù)庫。它的優(yōu)勢主要體現(xiàn)在：
1） 開源。意味著即使我們不去改也可以充分挖掘它，MS SQL除了看那些文檔，誰又知道它內(nèi)部如何實現(xiàn)。
2） 免費。意味著我們可以在大量垃圾服務(wù)器上裝大量的實例，即使它性能不怎么高，也架不住非常多的點啊。
3） 性能高。其它沒比較過，和MS SQL相比，同樣的應(yīng)用（主要是寫操作）一個撐500用戶就掛了，一個可以撐到2000。在數(shù)據(jù)量上到百萬之后，即使沒索引，MS SQL的插入性能下降的也一塌糊涂。其實任何事物都有相對性的，在變得復(fù)雜變得完善了之后會犧牲一部分的性能，MS SQL體現(xiàn)的是非常強的安全性數(shù)據(jù)完整性，這點是Mongodb辦不到的。
4） 配置簡單并且靈活。在生產(chǎn)環(huán)境中對數(shù)據(jù)庫配置故障轉(zhuǎn)移群集和讀寫分離的數(shù)據(jù)庫復(fù)制是很常見的需求，MS SQL的配置繁瑣的步驟還是很恐怖的，而Mongodb可以在五分鐘之內(nèi)配置自己所需要的故障轉(zhuǎn)移組，讀寫分離更是只需要一分鐘。靈活性體現(xiàn)在，我們可以配置一個M一個S，兩個M一個S（兩個M寫入的數(shù)據(jù)會合并到S上供讀取），一個M兩個S（一個M寫入的數(shù)據(jù)在兩個S上有鏡像），甚至是多個M多個S（理論上可以創(chuàng)建10個M，10個S，我們只需要通過輪詢方式隨便往哪個M上寫，需要讀的時候也可以輪訓(xùn)任意一個S，當(dāng)然我們要知道不可能保證在同一時間所有的S都有一致的數(shù)據(jù)）。那么也可以配置兩個M的對作為一套故障轉(zhuǎn)移群集，然后這樣的群集配置兩套，再對應(yīng)兩個S，也就是4個M對應(yīng)2個S，保證M點具有故障轉(zhuǎn)移。
5） 使用靈活。在之前的文章中我提到甚至可以通過SQL到JS表達式的轉(zhuǎn)換讓Mongodb支持SQL語句的查詢，不管怎么說Mongodb在查詢上還是很方便的。
之前也說過了，并不是所有數(shù)據(jù)庫應(yīng)用都使用采用Mongodb來替代的，它的主要缺點是：
1） 開源軟件的特點：更新快，應(yīng)用工具不完善。由于更新快，我們的客戶端需要隨著它的更新來升級才能享受到一些新功能，更新快也意味著很可能在某一階段會缺乏某個重要功能。另外我們知道MS SQL在DEV/DBA/ADM多個維度都提供了非常好的GUI工具對數(shù)據(jù)庫進行維護。而Mongodb雖然提供了一些程序，但是并不是非常友好。我們的DBA可能會很郁悶，去優(yōu)化Mongodb的查詢。
2） 操作事務(wù)。Mongodb不支持內(nèi)建的事務(wù)（沒有內(nèi)建事務(wù)不意味著完全不能有事務(wù)的功能），對于某些應(yīng)用也就不適合。不過對于大部分的互聯(lián)網(wǎng)應(yīng)用來說并不存在這個問題。
在使用Mongodb的過程中主要遇到下面的問題：
1） 真正的橫向擴展？在使用Memcache的過程中我們已經(jīng)體會到這種爽了，基本可以無限的增加機器來橫向擴展，因為什么，因為我們是通過客戶端來決定鍵值保存在那個實例上，在獲取的時候也很明確它在哪個實例上，即使是一次性獲取多個鍵值，也是同樣。而對于數(shù)據(jù)庫來說，我們通過各種各樣的方式進行了Sharding，不說其它的，在查詢的時候我們根據(jù)一定的條件獲取批量的數(shù)據(jù)，怎么樣去處理？比如我們按照用戶ID去分片，而查詢根本不在乎用戶ID，在乎的是用戶的年齡和教育程度，最后按照姓名排序，到哪里去取這些數(shù)據(jù)？不管是基于客戶端還是基于服務(wù)端的Sharding都是非常難做的，并且即使有了自動化的Sharding性能不一定能有保障。最簡單的是盡量按照功能來分，再下去就是歷史數(shù)據(jù)的概念，真正要做到實時數(shù)據(jù)分散在各個節(jié)點，還是很困難。
2） 多線程，多進程。在寫入速度達不到預(yù)期的情況下我們多開幾個線程同時寫，或者多開幾個Mongodb進程（同一機器），也就是多個數(shù)據(jù)庫實例，然后向不同的實例去寫。這樣是否能提高性能？很遺憾，非常有限，甚至可以說根本不能提高。為什么使用memcache的時候多開線程可以提高寫入速度？那是因為內(nèi)存數(shù)據(jù)交換的瓶頸我們沒達到，而對于磁盤來說，IO的瓶頸每秒那么幾十兆的是很容易達到的，一旦達到這個瓶頸了，無論是開多少個進程都無法提高性能了。還好Mongodb使用內(nèi)存映射，看到內(nèi)存使用的多了，其實我對它的信心又多了一點（內(nèi)存占用多了我覺得CPU更容易讓它不閑著），怕就怕某個DB不使用什么內(nèi)存，看著IO瓶頸到了，內(nèi)存和CPU還是吃不飽。
Memcache和Mongodb的配合
其實有了Memcache和Mongodb我們甚至可以讓80%以上的應(yīng)用擺脫傳統(tǒng)關(guān)系型數(shù)據(jù)庫。我能想到它們其實可以互相配合彌補對方的不足：
Memcache適合根據(jù)Key保存Value，那么有的時候我們并不知道需要讀取哪些Key怎么辦呢？我在想是不是可以把Mongodb或說數(shù)據(jù)庫當(dāng)作一個原始數(shù)據(jù)，這份原始數(shù)據(jù)中分為需要查詢的字段（索引字段）和普通的數(shù)據(jù)字段兩部分，把大量的非查詢字段保存在Memcache中，小粒度保存，在查詢的時候我們查詢數(shù)據(jù)庫知道要獲取哪些數(shù)據(jù)，一般查詢頁面也就顯示20-100條吧，然后一次性從Memcache中獲取這些數(shù)據(jù)。也就是說，Mongodb的讀的壓力主要是索引字段，而數(shù)據(jù)字段只是在緩存失效的時候才有用，使用Memcache擋住大部分實質(zhì)數(shù)據(jù)的查詢。反過來說，如果我們要清空Memcache中的數(shù)據(jù)也知道要清空哪些Key。