memcached應用場景

memcached最吸引人的地方主要在于它的分布式。分布式對于網際網路應用來講，按照用途基本上可劃分為三種方式：分布式計算、分布式存儲和兩者兼而有之。memcached是分布式存儲的一種。我們常見的分布式存儲大多數是将N台裝置（server或者單獨的存儲）建構成盤陣，而memcached旨在建構一個高速的記憶體池。更通俗一點來講：分布式計算是将N顆cpu組裝成一顆cpu，分布式慢速存儲是将N個硬碟組裝成一個大硬碟，memcached是将N塊記憶體組裝成一塊大記憶體。

    有個朋友問：那是不是代價很昂貴啊。我的回答是肯定的。如果你的網站規模隻有三兩台伺服器的話，我覺得你就不用考慮這樣的方案了，等你的網站做大了以後，再參考這方面的資料即可。一般都是比較大的網際網路公司為了追求更好的使用者體驗，才進行這方面的投資，對他們來講，使用者體驗至上，money是小case。

還有朋友問：有一些dbms提供記憶體表的功能，比如mysql的記憶體表，可以代替memcached。但我要建議你的是：mysql的記憶體表确實起到同樣的作用，但它的局限也很多，往往不能讓你随心所欲，是以建議你不要走彎路。

memcached的應用場景

應用範圍

    memcached産品或相關技術的應用，我們在前面已經提到了一些。其實它的應用還是非常普遍的，應用作為廣泛的領域：例如sns類網站、blog類網站、bbs類網站以及im背景服務。

 sns類網站的應用

    livejournal.com是99年始于校園中的項目，有點像中國的校内網。幾個學生純屬出于愛好做了這樣一個網站,主要實作以下功能： sns、blog、bbs和rss等。livejournal從建立開始就采用了大量的開源軟體，到現在它本身也衍生了不少開源軟體。 sns網站，現在比比皆是，規模比較大的象開心、校内、51，它們的頁面上往往需要引用大量的使用者資訊、好友資訊以及文章資訊等，是以跨表或跨庫操作會相當多。如果這些功能全部直接操作資料庫，顯然會帶來極大的效率損耗和系統負載。memcached在這樣的場景下就會發揮巨大的作用，它采用大記憶體把這些不變的資料全都緩存起來，當資料修改時就通知cache過期，這樣應用層基本上就可以解決大部分問題了，隻有很小一部分請求穿透應用層，用到資料庫。

 blog、bbs類網站的應用

   象blog.sina.com.cn這些流量巨大的blog系統，它需要頻繁讀寫的一些小資料。其中最典型的應用，我們通常成為“數字類服務”，比如blog中需要實時顯示的使用者點選數和閱讀數，bbs中需要記錄的線上人數、線上使用者等。這些小資料的處理非常繁瑣，你無論怎麼去設計資料庫，都很難避開跨表或者跨庫。有的朋友會說，可以在資料庫中增加備援字段解決這類問題，但事實上，這既不符合資料庫設計的範式規則，也很難做到資料的一緻性，由此會引發更為複雜的問題。而且由于産品線的分散發展，資料已經很難做到完全的統一規劃。memcached在這樣的場景下就會将這些小資料進行緩存，定期持久化就可以了，查詢操作一直都在記憶體中運作。說到這裡，有的朋友又會想到一些其它的問題：“memcached server當機了怎麼辦，怎麼保證與資料庫的資料一緻”。我會對你說：“你的問題非常好，我們将會在後面章節給出相應的解決方案”。另外，其實這種小資料并不是關鍵性資料，即使偶爾發生點錯誤，也沒太大的問題。blog、bbs系統并不是嚴格的企業級系統，假如你是為銀行業務提供解決方案的話，memcached并不适合。

 im server的應用

   前些時間， 有一些文章介紹memcached 在Jabber上應用。寫累了，喝口水，讀者自己去找找資料吧，有時間的話，幫我補上吧，呵呵。

   我們舉了幾個例子來說明memcached的應用場景，似乎都局限于小資料服務，那是不是就不能用于較大資料的緩沖了？那絕不是，memcached能夠用來存儲各種格式的資料，包括圖像、視訊、檔案以及資料庫檢索的結果等等，而且生産環境中就這麼跑過，隻不過讓大資料量使用緩沖的話，有點太浪費了，同樣數量的記憶體存不了幾條資料，是以會明顯的降低命中率。