承接上篇，筆者在撰寫前特意諮詢了新浪、金山、雅虎等一線大廠的前同事，並感謝網友對上篇文章的建設性評論。memcached 最迷人之處在於其分布式特性，對互聯網應用而言，分布式按用途可分為分布式計算、分布式存儲、兩者兼具。memcached 屬於分布式存儲，旨在構建高速記憶體池。通俗來說：分布式計算是將 N 顆 CPU 組裝成一顆 CPU，分布式慢速存儲是將 N 個硬盤組裝成一個大硬盤，而 memcached 是將 N 塊記憶體組裝成一塊大記憶體。
有朋友問成本是否高昂？答案是肯定的。若網站規模僅三兩台伺服器，無需考慮此方案，待業務做大後再參考。通常只有大型互聯網公司為極致用戶體驗才投資此架構，對他們而言用戶體驗至上，成本是小事。也有朋友提到 MySQL 記憶體表可替代 memcached，但其限制較多，難以隨心所欲，建議別走彎路。
memcached 應用極廣，涵蓋 SNS、Blog、BBS 類網站及 IM 後台服務等領域。
以 livejournal.com 為例（類似國內校內網），早期大量採用開源軟體並衍生出許多開源項目。SNS 網站（如開心網、校內網、51.com）頁面需引用大量用戶、好友、文章資訊，跨表跨庫操作頻繁。若全部直接操作資料庫，效率損耗與系統負載極大。memcached 以大記憶體緩存這些不常變動的數據，數據修改時通知 cache 過期，應用層即可解決大部分請求，僅極少數穿透至資料庫。
如 blog.sina.com.cn 這類流量巨大的系統，需頻繁讀寫「數字類服務」：Blog 的點擊數、閱讀數，BBS 的在線人數、在線用戶等。這類小數據處理繁瑣，無論如何設計資料庫都難避免跨表跨庫。增加冗餘字段雖可緩解，但違背範式規範，難保一致性，且因產品線分散導致數據難以統一規劃。memcached 緩存這些小數據並定期持久化，查詢全在記憶體進行。關於 memcached 宕機如何保證與資料庫一致性，將在後續章節給出方案。此外這類小數據非關鍵業務數據，偶發錯誤影響有限，Blog/BBS 非嚴格企業級系統，若為銀行業務則不適合用 memcached。
早有文章介紹 memcached 在 Jabber 上的應用，讀者可自行搜尋補充。
雖上述案例多集中於小數據服務，但 memcached 實際能存儲圖像、視頻、文件、資料庫查詢結果等各種格式數據，生產環境也有跑過。只是大數據量使用緩衝較浪費，同等記憶體存不了幾條數據，會明顯降低命中率。
