先說說自己對(duì)Memcached和Mongodb的一些看法，主要是拋磚引玉了，希望看到大家的意見和補(bǔ)充。

　　Memcached

　　Memcached的優(yōu)勢(shì)我覺得總結(jié)下來主要體現(xiàn)在：

　　1） 分布式。可以由10臺(tái)擁有4G內(nèi)存的機(jī)器，構(gòu)成一個(gè)40G的內(nèi)存池，如果覺得還不夠大可以增加機(jī)器，這樣一個(gè)大的內(nèi)存池，完全可以把大部分熱點(diǎn)業(yè)務(wù)數(shù)據(jù)保存進(jìn)去，由內(nèi)存來阻擋大部分對(duì)數(shù)據(jù)庫讀的請(qǐng)求，對(duì)數(shù)據(jù)庫釋放可觀的壓力。

　　2） 單點(diǎn)。如果Web服務(wù)器或App服務(wù)器做負(fù)載均衡的話，在各自內(nèi)存中保存的緩存可能各不相同，如果數(shù)據(jù)需要同步的話，比較麻煩（各自自己過期，還是分發(fā)數(shù)據(jù)同步？），即使數(shù)據(jù)并不需要同步，用戶也可能因?yàn)閿?shù)據(jù)的不一致而產(chǎn)生用戶體驗(yàn)上的不友好。

　　3） 性能強(qiáng)。不用懷疑和數(shù)據(jù)庫相比確實(shí)是，根源上還是內(nèi)存的讀寫和磁盤讀寫效率上幾個(gè)數(shù)量級(jí)的差距。有的時(shí)候我們?cè)诒г箶?shù)據(jù)庫讀寫太差的情況下可以看看磁盤的IO，如果確實(shí)是瓶頸的話裝啥強(qiáng)勁的數(shù)據(jù)庫估計(jì)也檔不了，強(qiáng)不強(qiáng)無非是這個(gè)數(shù)據(jù)庫多少充分的利用了內(nèi)存。

　　但是也不太建議在任何情況下使用Memcached替代任何緩存：

　　1） 如果Value特別大，不太適合。因?yàn)樵谀J(rèn)編譯下Memcached只支持1M的Value（Key的限制到不是最大的問題）。其實(shí)從實(shí)踐的角度來說也不建議把非常大的數(shù)據(jù)保存在Memcached中，因?yàn)橛行蛄谢葱蛄谢倪^程，別小看它消耗的CPU。說到這個(gè)就要提一下，我一直覺得Memcached適合面向輸出的內(nèi)容緩存，而不是面向處理的數(shù)據(jù)緩存，也就是不太適合把大塊數(shù)據(jù)放進(jìn)去拿出來處理之后再放進(jìn)去，而是適合拿出來就直接給輸出了，或是拿出來不需要處理直接用。

　　2） 如果不允許過期，不太適合。Memcached在默認(rèn)情況下最大30天過期，而且在內(nèi)存達(dá)到使用限制后它也會(huì)回收最少使用的數(shù)據(jù)。因此，如果我們要把它當(dāng)作static變量的話就要考慮到這個(gè)問題，必須有重新初始化數(shù)據(jù)的過程。其實(shí)應(yīng)該這么想，既然是緩存就是拿到了存起來，如果沒有必定有一個(gè)重新獲取重新緩存的過程，而不是想著它永遠(yuǎn)存在。

　　在使用Memcached的過程中當(dāng)然也會(huì)有一些問題或者說最佳實(shí)踐：

　　1） 清除部分?jǐn)?shù)據(jù)的問題。Memcached只是一個(gè)Key/Value的池，一個(gè)公共汽車誰都可以上。我覺得對(duì)于類似的公共資源，如果用的人都按照自己的規(guī)則來的話很容易出現(xiàn)問題。因此，最好在Key值的規(guī)范上上使用類似命名空間的概念， 每一個(gè)用戶都能很明確的知道某一塊功能的Key的范圍，或者說前綴。帶來的好處是我們?nèi)绻枰蹇盏脑捒梢愿鶕?jù)這個(gè)規(guī)范找到我們自己的一批Key然后再去清空，而不是清空所有的。當(dāng)然有人是采用版本升級(jí)的概念，老的Key就讓它過去吧，到時(shí)候自然會(huì)清空，這也是一種辦法。不過Key有規(guī)范總是有好處的，在統(tǒng)計(jì)上也方便一點(diǎn)。

　　2） Value的組織問題。也就是說我們存的數(shù)據(jù)的粒度，比如要保存一個(gè)列表，是一個(gè)保存在一個(gè)鍵值還是統(tǒng)一保存為一個(gè)鍵值，這取決于業(yè)務(wù)。如果粒度很小的話最好是在獲取的時(shí)候能批量獲取，在保存的時(shí)候也能批量保存。對(duì)于跨網(wǎng)絡(luò)的調(diào)用次數(shù)越少越好，可以想一下，如果一個(gè)頁面需要輸出100行數(shù)據(jù)，每一個(gè)數(shù)據(jù)都需要獲取一次，一個(gè)頁面進(jìn)行上百次連接這個(gè)性能會(huì)不會(huì)成問題。

　　那么Memcached主要用在哪些功能上呢？

　　其實(shí)我覺得平時(shí)能想到在內(nèi)存中做緩存的地方我們都可以考慮下是不是可以去適用分布式緩存，但是主要的用途還是用來在前端或中部擋一下讀的需求來釋放Web服務(wù)器App服務(wù)器以及DB的壓力。

　　Mongodb

　　Mongodb是一款比較優(yōu)良的非關(guān)系型數(shù)據(jù)庫的文檔型的數(shù)據(jù)庫。它的優(yōu)勢(shì)主要體現(xiàn)在：

　　1） 開源。意味著即使我們不去改也可以充分挖掘它，MS SQL除了看那些文檔，誰又知道它內(nèi)部如何實(shí)現(xiàn)。

　　2） 免費(fèi)。意味著我們可以在大量垃圾服務(wù)器上裝大量的實(shí)例，即使它性能不怎么高，也架不住非常多的點(diǎn)啊。

　　3） 性能高。其它沒比較過，和MS SQL相比，同樣的應(yīng)用（主要是寫操作）一個(gè)撐500用戶就掛了，一個(gè)可以撐到2000。在數(shù)據(jù)量上到百萬之后，即使沒索引，MS SQL的插入性能下降的也一塌糊涂。其實(shí)任何事物都有相對(duì)性的，在變得復(fù)雜變得完善了之后會(huì)犧牲一部分的性能，MS SQL體現(xiàn)的是非常強(qiáng)的安全性數(shù)據(jù)完整性，這點(diǎn)是Mongodb辦不到的。

　　4） 配置簡(jiǎn)單并且靈活。在生產(chǎn)環(huán)境中對(duì)數(shù)據(jù)庫配置故障轉(zhuǎn)移群集和讀寫分離的數(shù)據(jù)庫復(fù)制是很常見的需求，MS SQL的配置繁瑣的步驟還是很恐怖的，而Mongodb可以在五分鐘之內(nèi)配置自己所需要的故障轉(zhuǎn)移組，讀寫分離更是只需要一分鐘。靈活性體現(xiàn)在，我們可以配置一個(gè)M一個(gè)S，兩個(gè)M一個(gè)S（兩個(gè)M寫入的數(shù)據(jù)會(huì)合并到S上供讀取），一個(gè)M兩個(gè)S（一個(gè)M寫入的數(shù)據(jù)在兩個(gè)S上有鏡像），甚至是多個(gè)M多個(gè)S（理論上可以創(chuàng)建10個(gè)M，10個(gè)S，我們只需要通過輪詢方式隨便往哪個(gè)M上寫，需要讀的時(shí)候也可以輪訓(xùn)任意一個(gè)S，當(dāng)然我們要知道不可能保證在同一時(shí)間所有的S都有一致的數(shù)據(jù)）。那么也可以配置兩個(gè)M的對(duì)作為一套故障轉(zhuǎn)移群集，然后這樣的群集配置兩套，再對(duì)應(yīng)兩個(gè)S，也就是4個(gè)M對(duì)應(yīng)2個(gè)S，保證M點(diǎn)具有故障轉(zhuǎn)移。

　　5） 使用靈活。在之前的文章中我提到甚至可以通過SQL到JS表達(dá)式的轉(zhuǎn)換讓Mongodb支持SQL語句的查詢，不管怎么說Mongodb在查詢上還是很方便的。

　　之前也說過了，并不是所有數(shù)據(jù)庫應(yīng)用都使用采用Mongodb來替代的，它的主要缺點(diǎn)是：

　　1） 開源軟件的特點(diǎn)：更新快，應(yīng)用工具不完善。由于更新快，我們的客戶端需要隨著它的更新來升級(jí)才能享受到一些新功能，更新快也意味著很可能在某一階段會(huì)缺乏某個(gè)重要功能。另外我們知道MS SQL在DEV/DBA/ADM多個(gè)維度都提供了非常好的GUI工具對(duì)數(shù)據(jù)庫進(jìn)行維護(hù)。而Mongodb雖然提供了一些程序，但是并不是非常友好。我們的DBA可能會(huì)很郁悶，去優(yōu)化Mongodb的查詢。

　　2） 操作事務(wù)。Mongodb不支持內(nèi)建的事務(wù)（沒有內(nèi)建事務(wù)不意味著完全不能有事務(wù)的功能），對(duì)于某些應(yīng)用也就不適合。不過對(duì)于大部分的互聯(lián)網(wǎng)應(yīng)用來說并不存在這個(gè)問題。

　　在使用Mongodb的過程中主要遇到下面的問題：

　　1） 真正的橫向擴(kuò)展？在使用Memcached的過程中我們已經(jīng)體會(huì)到這種爽了，基本可以無限的增加機(jī)器來橫向擴(kuò)展，因?yàn)槭裁矗驗(yàn)槲覀兪峭ㄟ^客戶端來決定鍵值保存在那個(gè)實(shí)例上，在獲取的時(shí)候也很明確它在哪個(gè)實(shí)例上，即使是一次性獲取多個(gè)鍵值，也是同樣。而對(duì)于數(shù)據(jù)庫來說，我們通過各種各樣的方式進(jìn)行了Sharding，不說其它的，在查詢的時(shí)候我們根據(jù)一定的條件獲取批量的數(shù)據(jù)，怎么樣去處理？比如我們按照用戶ID去分片，而查詢根本不在乎用戶ID，在乎的是用戶的年齡和教育程度，最后按照姓名排序，到哪里去取這些數(shù)據(jù)？不管是基于客戶端還是基于服務(wù)端的Sharding都是非常難做的，并且即使有了自動(dòng)化的Sharding性能不一定能有保障。最簡(jiǎn)單的是盡量按照功能來分，再下去就是歷史數(shù)據(jù)的概念，真正要做到實(shí)時(shí)數(shù)據(jù)分散在各個(gè)節(jié)點(diǎn)，還是很困難。

　　2） 多線程，多進(jìn)程。在寫入速度達(dá)不到預(yù)期的情況下我們多開幾個(gè)線程同時(shí)寫，或者多開幾個(gè)Mongodb進(jìn)程（同一機(jī)器），也就是多個(gè)數(shù)據(jù)庫實(shí)例，然后向不同的實(shí)例去寫。這樣是否能提高性能？很遺憾，非常有限，甚至可以說根本不能提高。為什么使用Memcached的時(shí)候多開線程可以提高寫入速度？那是因?yàn)閮?nèi)存數(shù)據(jù)交換的瓶頸我們沒達(dá)到，而對(duì)于磁盤來說，IO的瓶頸每秒那么幾十兆的是很容易達(dá)到的，一旦達(dá)到這個(gè)瓶頸了，無論是開多少個(gè)進(jìn)程都無法提高性能了。還好Mongodb使用內(nèi)存映射，看到內(nèi)存使用的多了，其實(shí)我對(duì)它的信心又多了一點(diǎn)（內(nèi)存占用多了我覺得CPU更容易讓它不閑著），怕就怕某個(gè)DB不使用什么內(nèi)存，看著IO瓶頸到了，內(nèi)存和CPU還是吃不飽。

　　Memcached和Mongodb的配合

　　其實(shí)有了Memcached和Mongodb我們甚至可以讓80%以上的應(yīng)用擺脫傳統(tǒng)關(guān)系型數(shù)據(jù)庫。我能想到它們其實(shí)可以互相配合彌補(bǔ)對(duì)方的不足：

　　Memcached適合根據(jù)Key保存Value，那么有的時(shí)候我們并不知道需要讀取哪些Key怎么辦呢？我在想是不是可以把Mongodb或說數(shù)據(jù)庫當(dāng)作一個(gè)原始數(shù)據(jù)，這份原始數(shù)據(jù)中分為需要查詢的字段（索引字段）和普通的數(shù)據(jù)字段兩部分，把大量的非查詢字段保存在Memcached中，小粒度保存，在查詢的時(shí)候我們查詢數(shù)據(jù)庫知道要獲取哪些數(shù)據(jù)，一般查詢頁面也就顯示20-100條吧，然后一次性從Memcached中獲取這些數(shù)據(jù)。也就是說，Mongodb的讀的壓力主要是索引字段，而數(shù)據(jù)字段只是在緩存失效的時(shí)候才有用，使用Memcached擋住大部分實(shí)質(zhì)數(shù)據(jù)的查詢。反過來說，如果我們要清空Memcached中的數(shù)據(jù)也知道要清空哪些Key。

it知識(shí)庫：Memcached and Mongodb，轉(zhuǎn)載需保留來源！

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