首先說明下memcached存在如下問題
本身沒有內置分布式功能，無法實現使用多台Memcache服務器來存儲不同的數據，最大程度的使用相同的資源；無法同步數據，容易造成單點故障。（memagent代理實現集群）
在 Memcached中可以保存的item數據量是沒有限制的，只要內存足夠 。
Memcached單進程最大使用內存為2G，要使用更多內存，可以分多個端口開啟多個Memcached進程
最大30天的數據過期時間,設置為永久的也會在這個時間過期，常量REALTIME_MAXDELTA
60*60*24*30控制
最大鍵長為250字節，大於該長度無法存儲，常量KEY_MAX_LENGTH 250控制
單個item最大數據是1MB，超過1MB數據不予存儲，常量POWER_BLOCK 1048576進行控制，
它是默認的slab大小
最大同時連接數是200，通過 conn_init()中的freetotal進行控制，最大軟連接數是1024，通過
settings.maxconns=1024 進行控制
跟空間占用相關的參數：settings.factor=1.25, settings.chunk_size=48, 影響slab的數據占用和步進方式
memcached是一種無阻塞的socket通信方式服務，基於libevent庫，由於無阻塞通信，對內存讀寫速度非常之快。
memcached分服務器端和客戶端，可以配置多個服務器端和客戶端，應用於分布式的服務非常廣泛。
memcached作為小規模的數據分布式平台是十分有效果的。
memcached是鍵值一一對應，key默認最大不能超過128個字 節，value默認大小是1M，也就是一個slabs，如果要存2M的值（連續的），不能用兩個slabs，因為兩個slabs不是連續的，無法在內存中 存儲，故需要修改slabs的大小，多個key和value進行存儲時，即使這個slabs沒有利用完，那么也不會存放別的數據。
集群配置
由於Memcached服務器與服務器之間沒有任何通訊，並且不進行任何數據復制備份，所以當任何服務器節點出現故障時，會出現單點故障，如果需要實現HA，則需要通過另外的方式來解決。
通過Magent緩存代理，防止單點現象，緩存代理也可以做備份，通過客戶端連接到緩存代理服務器，緩存代理服務器連接緩存連接服務器，緩存代理服務器可以連接多台Memcached機器可以將每台Memcached機器進行數據同步。如果其中一台緩存服務器down機，系統依然可以繼續工作，如果其中一台Memcached機器down掉，數據不會丟失並且可以保證數據的完整性。具體可以參考：http://code.google.com/p/memagent/
memcache集群的實現
memcached盡管是“分布式”緩存服務器，但服務器端並沒有分布式功能。各個memcached不會互相通信以共享信息。那么，怎樣進行分布式呢？這完全取決於客戶端的實現。
memcached的分布式
Memcached作為集中式Cache，就存在着集中式的致命問題：單點問題，Memcached支持多Instance分布在多台機器上，僅僅只是解決了數據全部丟失的問題，但是當其中一台機器出錯以后，還是會導致部分數據的丟失，一個籃子掉在地上還是會把部分的雞蛋打破。
因此就需要實現一個備份機制，能夠保證Memcached在部分失效以后，數據還能夠依然使用，當然大家很多時候都用Cache不命中就去數據源獲取的策略，但是在SIP的場景中，如果部分信息找不到就去數據庫查找，那么要把SIP弄垮真的是很容易，因此SIP對於Memcached中的數據認為是可信的，因此做Cluster也是必要的。
1.應用傳入需要操作的key，通過CacheManager獲取配置在Cluster中的客戶端。
2.當獲得Cache Client以后，執行Cache操作。
3. A.如果是讀取操作，當不能命中時去集群其他Cache客戶端獲取數據，如果獲取到數據，嘗試寫入到本次獲得的Cache客戶端，並返回結果。（達到數據恢復的作用）
B.如果是更新操作，在本次獲取得Cache客戶端執行更新操作以后，立即返回，將更新集群其他機器命令提交給客戶端的異步更新線程對列去異步執行。（由於如果是根據key來獲取Cache，那么異步執行不會影響到此主鍵的查詢操作）
存在的問題：如果是設置了Timeout的數據，那么在丟失以后被復制的過程中就會變成永久有效的內容。
越來越感覺到DB力不從心，在面對千萬級用戶量的應用時，DB面對平凡的curd，特別是查詢的時候，早已不堪重負！如何解決高並發下數據的查詢效率，在應用中顯的越來越重要，好了廢話不多說，首先介紹下magent與memcached
一、 magent
magent是一款開源的Memcached代理服務器軟件，其項目網址為：http://code.google.com/p/memagent/
1. 安裝：
1.mkdir magent
2.cd magent/
3.wget http://memagent.googlecode.com/files/magent-0.5.tar.gz
4.tar zxvf magent-0.5.tar.gz
5./sbin/ldconfig
6.sed -i "s#LIBS = -levent#LIBS = -levent -lm#g" Makefile
7.make
8.cp magent /usr/bin/magent
9.cd ../
2. magent 命令參數說明：
1.-h this message
2.-u uid
3.-g gid
4.-p port, default is 11211. (0 to disable tcp support)
5.-s ip:port, set memcached server ip and port
6.-b ip:port, set backup memcached server ip and port
7.-l ip, local bind ip address, default is 0.0.0.0
8.-n number, set max connections, default is 4096
9.-D do not go to background
10.-k use ketama key allocation algorithm
11.-f file, unix socket path to listen on. default is off
12.-i number, max keep alive connections for one memcached server, default is 20
13.-v verbose
二、memcached http://memcached.org/
1. 安裝libevent
- tar zxvf libevent-1.4.13-stable.tar.gz
- cd libevent-1.4.13-stable
- ./configure --prefix=/usr
- make
- make install
2. 安裝memcached
- tar zxvf memcached-1.4.5.tar.gz
- cd memcached-1.4.5.tar.gz
- ./configure --with-libevent=/usr
configure 需要加 libevent的安裝路徑
- make
- make install
- 安裝完成后會把memcached放到 /usr/local/bin/memcached
啟動： /usr/local/bin/memcached -d -m 512 -u root -p 11211 -c 10000 -M -f 1.1 -P /tmp/memcached.pid
三、配置memcached 與 magent，無圖無真相，一圖抵千言：
magent與memcached 是可以混搭的，不必死板的一個magent s-memcached s-memcached b-memcached
上圖此模型已經能夠很好的解決一個節點，一組服務器的緩存數據服務，但是如果在北方網通架設了一組服務器，同時在南方電信又架設了另外一組服務器，那么這兩組相對獨立的節點之間如何做到數據的同步與共享，基於magent與memcached的解決方案如下：
需要注意的是，兩組magent的配置最好完全一致，比如：
北方的magent配置為：magent s-memcached1 s-memcached2 b-memcached3
那么南方的magent配置也為：magent s-memcached1 s-memcached2 b-memcached3
其順序都是一致的，因為magent在分配key到memcached上時只是簡單的使用散列余數算法。
當然如果你夠懶，那么你可以直接連接備份magent，因為所有的數據上面都有。
有個特別要注意的地方是：
1:其中一台Memcached死掉，從magent取數據，數據會從備份的Memcached取出，保證用戶不受影響.
2:Memcached重啟復活，由於這兩台Memcached重啟后無數據，因此magent取得的將是空值，盡管備份Memcached還有數據。可采用定時維護服務器，恢復memcached。
3。如果Memcached死掉,備份機同時死掉，那么只能說明你夠倒霉，此時此刻你或許能見到上帝。
四、java客戶端
推薦使用：xmemcached
http://code.google.com/p/xmemcached/
五、緩存與DB的同步
比較保險的做法是：查詢的時候從緩存中取，add、updae、delete的時候同時操作緩存與DB。
當然你也可以定時同步緩存與DB的數據，個人認為不同的業務應該有不同的選擇！
我在實際的應用中是同時使用這兩種方式，比如用戶個人信息之類的內容，就用定時同步的方式。
六、搜索引擎+緩存+DB
這個主題比較大，可以分為：
1。文件結構的存儲代替DB持久化存儲。
2。緩存在搜索引擎中的使用--文本庫與索引庫的緩存實現。
3。使用搜索引擎進行統一的數據查詢。
4。文件同步讀寫。