這次是Fotolog的經驗，傳說中比Flickr更大的網站，Fotolog在21台服務器上部署了51個memcached實例，總計有254G緩存空間可用，緩存了多達175G的內容，這個數量比很多網站的數據庫都要大的多，原文是A Bunch of Great Strategies for Using Memcached and MySQL Better Together，我這裡還是選擇性的翻譯以及按照我的理解補充，感謝Todd Hoff，總能給我們一些學習的案例，從這裡也能看出國外技術的開放態度，不似我們，其實就那麼點小九九還藏著掖著，好了，進入正題。
一、關於memcached
還不知道這個?那你去面試的時候要吃虧了，趕緊去官方網站看一下http://www.danga.com/memcached/，另外google一下用法，硬盤總是太慢，把數據存在內存裡面吧，如果你只有一台服務器，推薦用一下APC(Facebook在用)或者eaccelerator或者Xcache(國人開發的)，這些產品單機效果更好，如果你需要分布式的緩存方案，那麼用memcached吧。
二、memcached如何與mysql並肩作戰?
通過數據庫分片來解決數據庫寫擴展的問題把數據庫分片，部署到不同的服務器上，免得只有一個主服務器，寫操作成為瓶頸以及可能有的“單點故障”，一般的數據庫分片主要是按照業務來分，盡可能的拆分業務，不相干的都獨立起來做成服務也好
前 端mysql和一堆memcached服務器來應付讀的問題應用程序首先從memcached中獲取數據，獲取不到再從數據庫中獲得並保存在 memcached中，以前看過一篇文章說好的應用95%的數據從memcache的中獲得，3%的數據從mysql的query cache中獲得，剩下2%才去查表，對比一下你的應用，差距有多遠?
通過mysql復制(master-slave)來解決讀的問題
首先mysql數據庫通過master-slave讀寫分離，多個slave來應對應用程序讀的操作。
三、為什麼不用mysql的query cache?
我們都知道mysql有個query cache，可以緩存上次查詢的結果，可實際上幫不上太多的忙，下面是mysql quety cache的不足：
只能有一個實例
意味著你能存儲內容的上限就是你服務器的可用內存，一台服務器能有多少內存?你又能存多少呢?
只要有寫操作，mysql的query cache就失效
只要數據庫內容稍有改變，那怕改變的是其他行，mysql的query cache也會失效
mysql的query cache只能緩存數據庫數據行
意味著其他內容都不行，比如數組，比如對象，而memcached理論上可以緩存任何內容，甚至文件^_^
