Redis3.0集羣方案分析

     在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