Xmemcached在元旦左右準備發1.3這個版本，這個版本新增加的一個關鍵特性就是所謂的failure模式。關于這個，可以看下memcached官方文檔的解釋
《Failure,or Failover》。
展開來說，在某個memcached節點掛掉或者由于其他故障連接斷開的時候，大部分客戶端的默認策略都是failover的，也就是會查找下一個可用的memcached節點繼續使用，掛掉或者連接不上的節點的數據會轉移到其他節點上，路由的策略可以是Round Robin，也可以是一致性哈希。這樣的模式在節點意外故障掛掉的情況下運行的很好，但是memached節點也完全可能因為一個意外的事故而
短暫掛掉，比如你不小心弄掉了網線又馬上接上去，比如機房交換機突然停電又立即恢復了，假設在故障前，用戶A正要更新數據到節點A，節點A意外斷開，那么這些數據就更新到下一個有效節點B，但是節點A又馬上恢復，這時候用戶又從節點A去讀數據，讀到卻是更新前的老數據了（新數據更新到B節點去了），這種情況對用戶來說就非常困惑，你告訴我更新成功，但是看到卻還是更新前的數據。
怎么解決呢？一個簡單的方案就是所謂failure模式，當某個節點掛掉的時候，不會從節點列表移除，請求也不會轉移到下一個有效節點，而是直接將請求置為失敗，就剛才的場景來說，在用戶更新數據到節點A的時候，節點A意外斷開，那么用戶的這次更新請求不會轉移到節點B，而是直接告訴用戶更新失敗，用戶再次查詢數據則繞過節點A直接查詢后端存儲。這種模式很適合這種節點短暫不可用的狀況，請求會穿透緩存到后端，但是避免了新舊數據的問題。
Xmemcached 1.3將支持failure模式，只要你設置下failureMode為true即可，簡單示例：
XMemcachedClientBuilder builder =……
//設置使用failure模式
builder.setFailureMode(true);
在此模式下，某個節點掛掉的情況下，往這個節點的請求都將直接拋出MemcachedException的異常。
不僅如此，xmemcached 1.3還將引入standby node的概念，你可以設置某個memached節點的備份節點，當這個節點掛掉的時候會將請求轉發給這個備份節點，不會簡單地拋出異常，也不會轉發給其他節點。要使用standby node，必須首先設置使用failure mode，一個例子：
XMemcachedClientBuilder builder = new XMemcachedClientBuilder(AddrUtil
.getAddressMap("192.168.1.99:11211,192.168.1.100:11211 192.168.1.101:11211,192.168.1.102:11211"));
builder.setFailureMode(true);
可以看到，新的服務器字符串格式變化為host:port,host:port host:port,host:port的格式，以空格隔開的是兩個節點組成的一個分組，以逗號隔開的是主節點和備份節點，以上面的例子來說，我們設置客戶端使用的節點是192.168.1.99和192.168.1.101，其中99對應的備份節點是100，而101的備份節點是102。并且我們需要設置使用failure mode為true。
Failure mode加上standby節點可以比較好的解決新舊數據的問題，并且也可以防止請求穿透緩存到DB，但是主備兩個節點之間的數據同步，xmemcached不準備幫你做，我的建議是可以使用repcached這個patch做復制。
有的朋友可能希望，在使用備份節點之前先flush掉備份節點的數據，防止使用到老的數據，請求還是可以穿透緩存去DB查找，并存儲到備份節點，我仔細考慮了這個方案，衡量之下還是不準備做自動flush，主要是并發上很難處理，并且flush數據這個事情可以手工來搞，根據我的經驗，做的太透明太自動不一定是好事。你可以在主節點恢復之后，手工flush下備份節點的數據。
目前，xmemcached 1.3已經整裝待發，對這些特性有興趣的朋友可以先從
svn下載源碼嘗鮮，有任何改進的建議請發郵件給我。我的郵件地址在博客的右上角。