在Redis3.0集群出來之前，大家都對作者antirez寄予厚望，因為Redis從來沒有讓我們失望過。現在Redis3.0集群出來了，網上出了很多評論文章，都說他的功能多么強大，包括下面這張圖是徹底把我欺騙了。
等到我把Redis3.0客戶端庫hiredis編譯好集成到公司系統，訪問其中一台Redis3.0服務器居然返回"MOVED 2318 10.12.8.156
:6379"，這才了解到訪問其他Redis3.0服務器的Key需要二次定位，這就是Redis3.0所謂的ASK 轉向/MOVED 轉向機制，這絕對
是一個大坑，網上既然沒有人說出來，如果我不站出來，會有人繼續掉進這個大坑。
Redis最初的使命是用高效的內存取代復雜繁重的數據庫，如果從緩存服務器獲取一個Key要經過二次定位，訪問時間是原來單機
緩存服務器的兩倍，那樣我們還不如直接用數據庫呢。
鑒於Redis3.0所謂的ASK 轉向/MOVED 轉向機制，網上推出了JAVA版的Redis3.0客戶端庫jedis、C++版的Redis3.0客戶端
庫ACL，他們都支持根據Redis服務器居返回"MOVED"信息進行二次定位數據訪問，而且還有在主備切換的情況下訪問備機的功能，
正常情況下Redis3.0集群要部署3台主機和3台備機，這樣客戶端就要同時維持這6台服務器的長連接，像我們公司的系統有上百個
進程，一個線程就要維持6台緩存服務器的長連接，一個進程擁有多個線程，總的算起來差不多上千個緩存服務器的長連接，這無異
於飲鴆止渴。
最理想的方案就是Redis3.0 Cluster加入集群代理功能，實現客戶端通過任何一台緩存服務器一次性定位所有的Key，當然這要等待
antirez發力，短期看似乎不大可能；客戶端優化方案就是加入計算Key的哈希槽值的邏輯，加載服務器端的哈希槽存儲邏輯，來實現一次
性定位訪問緩存服務器，這樣做的缺陷還是避免不了多台緩存服務器的長連接，同時一旦緩存服務器發生數據遷移和主備切換的情況，客
戶端就得變更哈希槽存儲邏輯。
俗話說，自力更生，豐衣足食。我們為何不自己開發一個Redis緩存集群代理服務器系統，取名為RedisClusterProxy，多牛B啊！
系統構思：系統並發接收客戶端請求，計算Key的哈希槽值，加載服務器端的哈希槽存儲邏輯，轉發到對應的緩存服務器，並將緩存服
務器的返回值回傳給客戶端，這樣客戶端只要訪問集群代理系統，實現一次性定位訪問，效率與單台緩存服務器相差無幾，協議還是采
用Redis3.0客戶端和服務端的通信協議，這樣不用對Redis3.0的客戶端和服務器源碼做任何改動，另外將服務器端的哈希槽存儲邏輯
定時動態加載到系統，一旦緩存服務器發生數據遷移和主備切換的情況就不會發生訪問定位不准確的問題，就算antirez將集群代理功能
加入Redis3.0，我們的客戶端系統也不用做任何更改。
RedisClusterProxy(http://download.csdn.net/detail/g55395162/8844927)系統初步開發花了一個星期時間，相關功能和框架已經實現，可以編譯測試，后續進一步優化。
上面連接為試用版，正式版解決了試用版的所有BUG，穩定性和並發性能更高，並實現緩存服務器主備切換同步更新連接，采用多進程，分布式部署，什么Codis,twemproxy等都可以比下去，有需要的可以聯系我13640963760。
正式版見http://bbs.chinaunix.net/thread-4188675-1-1.html