Memcache and Mongodb

 

Memcache

 

Memcache的優勢我覺得總結下來主要體現在：

1） 分佈式。可以由10臺擁有4G內存的機器，構成一個40G的內存池，如果覺得還不夠大可以增加機器，這樣一個大的內存池，完全可以把大部分熱點業務數據保存進去，由內存來阻擋大部分對數據庫讀的請求，對數據庫釋放可觀的壓力。

2） 單點。如果Web服務器或App服務器做負載均衡的話，在各自內存中保存的緩存可能各不相同，如果數據需要同步的話，比較麻煩（各自自己過期，還是分發數據同步？），即使數據並不需要同步，用戶也可能因爲數據的不一致而產生用戶體驗上的不友好。

3） 性能強。不用懷疑和數據庫相比確實是，根源上還是內存的讀寫和磁盤讀寫效率上幾個數量級的差距。有的時候我們在抱怨數據庫讀寫太差的情況下可以看看磁盤的IO，如果確實是瓶頸的話裝啥強勁的數據庫估計也檔不了，強不強無非是這個數據庫多少充分的利用了內存。

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

1） 如果Value特別大，不太適合。因爲在默認編譯下Memcache只支持1M的Value（Key的限制到不是最大的問題）。其實從實踐的角度來說也不建議把非常大的數據保存在Memcache中，因爲有序列化反序列化的過程，別小看它消耗的CPU。說到這個就要提一下，我一直覺得Memcache適合面向輸出的內容緩存，而不是面向處理的數據緩存，也就是不太適合把大塊數據放進去拿出來處理之後再放進去，而是適合拿出來就直接給輸出了，或是拿出來不需要處理直接用。

2） 如果不允許過期，不太適合。Memcache在默認情況下最大30天過期，而且在內存達到使用限制後它也會回收最少使用的數據。因此，如果我們要把它當作static變量的話就要考慮到這個問題，必須有重新初始化數據的過程。其實應該這麼想，既然是緩存就是拿到了存起來，如果沒有必定有一個重新獲取重新緩存的過程，而不是想着它永遠存在。

在使用Memcache的過程中當然也會有一些問題或者說最佳實踐：

1） 清除部分數據的問題。Memcache只是一個Key/Value的池，一個公共汽車誰都可以上。我覺得對於類似的公共資源，如果用的人都按照自己的規則來的話很容易出現問題。因此，最好在Key值的規範上上使用類似命名空間的概念， 每一個用戶都能很明確的知道某一塊功能的Key的範圍，或者說前綴。帶來的好處是我們如果需要清空的話可以根據這個規範找到我們自己的一批Key然後再去清空，而不是清空所有的。當然有人是採用版本升級的概念，老的Key就讓它過去吧，到時候自然會清空，這也是一種辦法。不過Key有規範總是有好處的，在統計上也方便一點。

2） Value的組織問題。也就是說我們存的數據的粒度，比如要保存一個列表，是一個保存在一個鍵值還是統一保存爲一個鍵值，這取決於業務。如果粒度很小的話最好是在獲取的時候能批量獲取，在保存的時候也能批量保存。對於跨網絡的調用次數越少越好，可以想一下，如果一個頁面需要輸出100行數據，每一個數據都需要獲取一次，一個頁面進行上百次連接這個性能會不會成問題。

那麼Memcache主要用在哪些功能上呢？

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

 

Mongodb

 

Mongodb是一款比較優良的非關係型數據庫的文檔型的數據庫。它的優勢主要體現在：

1） 開源。意味着即使我們不去改也可以充分挖掘它，MS SQL除了看那些文檔，誰又知道它內部如何實現。

2） 免費。意味着我們可以在大量垃圾服務器上裝大量的實例，即使它性能不怎麼高，也架不住非常多的點啊。

3） 性能高。其它沒比較過，和MS SQL相比，同樣的應用（主要是寫操作）一個撐500用戶就掛了，一個可以撐到2000。在數據量上到百萬之後，即使沒索引，MS SQL的插入性能下降的也一塌糊塗。其實任何事物都有相對性的，在變得複雜變得完善了之後會犧牲一部分的性能，MS SQL體現的是非常強的安全性數據完整性，這點是Mongodb辦不到的。

4） 配置簡單並且靈活。在生產環境中對數據庫配置故障轉移羣集和讀寫分離的數據庫複製是很常見的需求，MS SQL的配置繁瑣的步驟還是很恐怖的，而Mongodb可以在五分鐘之內配置自己所需要的故障轉移組，讀寫分離更是只需要一分鐘。靈活性體現在，我們可以配置一個M一個S，兩個M一個S（兩個M寫入的數據會合併到S上供讀取），一個M兩個S（一個M寫入的數據在兩個S上有鏡像），甚至是多個M多個S（理論上可以創建10個M，10個S，我們只需要通過輪詢方式隨便往哪個M上寫，需要讀的時候也可以輪訓任意一個S，當然我們要知道不可能保證在同一時間所有的S都有一致的數據）。那麼也可以配置兩個M的對作爲一套故障轉移羣集，然後這樣的羣集配置兩套，再對應兩個S，也就是4個M對應2個S，保證M點具有故障轉移。

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

之前也說過了，並不是所有數據庫應用都使用採用Mongodb來替代的，它的主要缺點是：

1） 開源軟件的特點：更新快，應用工具不完善。由於更新快，我們的客戶端需要隨着它的更新來升級才能享受到一些新功能，更新快也意味着很可能在某一階段會缺乏某個重要功能。另外我們知道MS SQL在DEV/DBA/ADM多個維度都提供了非常好的GUI工具對數據庫進行維護。而Mongodb雖然提供了一些程序，但是並不是非常友好。我們的DBA可能會很鬱悶，去優化Mongodb的查詢。

2） 操作事務。Mongodb不支持內建的事務（沒有內建事務不意味着完全不能有事務的功能），對於某些應用也就不適合。不過對於大部分的互聯網應用來說並不存在這個問題。

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

1） 真正的橫向擴展？在使用Memcache的過程中我們已經體會到這種爽了，基本可以無限的增加機器來橫向擴展，因爲什麼，因爲我們是通過客戶端來決定鍵值保存在那個實例上，在獲取的時候也很明確它在哪個實例上，即使是一次性獲取多個鍵值，也是同樣。而對於數據庫來說，我們通過各種各樣的方式進行了Sharding，不說其它的，在查詢的時候我們根據一定的條件獲取批量的數據，怎麼樣去處理？比如我們按照用戶ID去分片，而查詢根本不在乎用戶ID，在乎的是用戶的年齡和教育程度，最後按照姓名排序，到哪裏去取這些數據？不管是基於客戶端還是基於服務端的Sharding都是非常難做的，並且即使有了自動化的Sharding性能不一定能有保障。最簡單的是儘量按照功能來分，再下去就是歷史數據的概念，真正要做到實時數據分散在各個節點，還是很困難。

2） 多線程，多進程。在寫入速度達不到預期的情況下我們多開幾個線程同時寫，或者多開幾個Mongodb進程（同一機器），也就是多個數據庫實例，然後向不同的實例去寫。這樣是否能提高性能？很遺憾，非常有限，甚至可以說根本不能提高。爲什麼使用memcache的時候多開線程可以提高寫入速度？那是因爲內存數據交換的瓶頸我們沒達到，而對於磁盤來說，IO的瓶頸每秒那麼幾十兆的是很容易達到的，一旦達到這個瓶頸了，無論是開多少個進程都無法提高性能了。還好Mongodb使用內存映射，看到內存使用的多了，其實我對它的信心又多了一點（內存佔用多了我覺得CPU更容易讓它不閒着），怕就怕某個DB不使用什麼內存，看着IO瓶頸到了，內存和CPU還是吃不飽。

 

Memcache和Mongodb的配合

 

其實有了Memcache和Mongodb我們甚至可以讓80%以上的應用擺脫傳統關係型數據庫。我能想到它們其實可以互相配合彌補對方的不足：

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