memcached如何處理容錯的？
不處理！:) 在memcached節點失效的情況下，集群沒有必要做任何容錯處理。如果發生了節點失效，應對的措施完全取決于用戶。節點失效時，下面列出幾種方案供您選擇：
* 忽略它！ 在失效節點被恢復或替換之前，還有很多其他節點可以應對節點失效帶來的影響。
* 把失效的節點從節點列表中移除。做這個操作千萬要小心！在默認情況下（余數式哈希算法），客戶端添加或移除節點，會導致所有的緩存數據不可用！因為哈希參照的節點列表變化了，大部分key會因為哈希值的改變而被映射到（與原來）不同的節點上。
* 啟動熱備節點，接管失效節點所占用的IP。這樣可以防止哈希紊亂（hashing chaos）。 ”
同學們，根據上面的說法，memcached其中一個節點失效以后，memcached本身是沒有任何策略維持失效轉發的，這對于大型系統是一個無法接受的事實。 Memcached分布式每個服務器端本身沒有相互相連的關系，數據分布是由客戶端來維持的，也可以說Memcached還沒有為集群提供真的高可用方案，因為從集群的定義上來說需要滿足：1.壓力分載 2.失效轉發。
在項目組中lianjie.you同學問我如果在分布式中的其中一臺Memcached節點down掉了，應該如何解決？我當時愣住了，一時之間還不能給出任何完整的答案。
今早在座公車來上班的路上用手機上網Google了一下，發現原來在網上有很多人與我們有相同的問題，我Google的關鍵字是 “Memcached 單點” 、“Memcached 單點故障”。給出的搜索結果都不算讓人滿意，我才打算寫一篇關于解決集群中Memcached單點故障的文章。Javabloger只向大家提供2種解決 思路，暫時不提供具體代碼。
現象描述：
在客戶端連接的部分寫入多個服務器端的ip地址，客戶端將會自動的把緩存數據分布的放在每個不同的機器上，如圖所示：
查看大圖請點擊這里
現象后果：
如果其中一個緩存節點的機器down機，那么客戶端存入的緩存數據將會丟失一部分，就是圖中紅色字體描述的“Losed 33% Cache Data”，也就是說那部分數據徹底沒有了！如果是用戶的關鍵性信息那么就玩大了，如圖所示：
查看大圖請點擊這里
解決方案1：本地備份緩存
在本地放一份緩存，同時也在分布式Memcached上放一份緩存，如果當其中一臺節點當機了，客戶端程序直接讀取本地的緩存，本地客戶端維護一個HashMap即可，這樣的方案雖然很簡陋，但是可以滿足一部分場景的需要，當你很急需的時候可以作為臨時方案暫時替代一下。
解決方案2：采用緩存代理服務器
采用 Magent 緩存代理，防止單點現象，緩存代理也可以做備份，通過客戶端連接到緩存代理服務器，緩存代理服務器連接緩存服務器，緩存代理服務器可以連接多臺Memcached機器可以將每臺Memcached機器進行數據同步。這樣的架構比較完善了，如果其中一臺緩存代理服務器down機，系統依然可以繼續工作，如果其中一臺Memcached機器down掉，數據不會丟失并且可以保證數據的完整性，以上描述的系統架構如圖所示：
查看大圖請點擊這里
還是那句話：沒有任何架構是最完美的，只是最合適的，任何架構都不可能一步到位，都是經過一步一步演變過來的。