Redis 實踐之叢集方案

標籤：style   blog   http   color   java   ar   資料   sp   log   

本文原創自 http://blog.csdn.net/voipmaker  轉載註明出處。

Redis叢集的目的是實現資料的橫向伸縮，把一塊資料分區儲存到多個機器，可以橫向擴充資料庫大小，擴充頻寬，計算能力等。

 

實現資料分區(叢集)方式大致有三種：

 

（1）     用戶端實現資料分區

即用戶端自己計算資料的key應該在哪個機器上儲存和尋找，此方法的好處是降低了伺服器叢集的複雜度，用戶端實現資料分區時，伺服器是獨立的，伺服器之前沒有任何關聯。多數redis用戶端庫實現了此功能，也叫sharding,這種方式的缺點是用戶端需要即時知道當前叢集節點的聯絡資訊，

同時，當添加一個新的節點時，用戶端要支援動態sharding.，多數用戶端實現不支援此功能，需要重啟redis。另一個弊端是redis的HA需要額外考慮。

 

（2）     伺服器實現資料分區

其理論是，用戶端隨意與叢集中的任何節點通訊，伺服器端負責計算某個key在哪個機器上，當用戶端訪問某台機器時，伺服器計算對應的key應該儲存在哪個機器，然後把結果返回給用戶端，用戶端再去對應的節點操作key，是一個重新導向的過程，此方式是redis3.0正在實現，目前處於beta版本， Redis 3.0的叢集同時支援HA功能，某個master節點掛了後，其slave會自動接管。

伺服器端實現叢集需要用戶端語言實現伺服器叢集的協議，目前java，php，ruby用戶端多數有redis-cluster用戶端實現版本。

 

（3）     通過Proxy 伺服器實現資料分區

 

此方式是藉助一個Proxy 伺服器實現資料分區，用戶端直接與proxy聯絡，proxy計算叢集節點資訊，並把請求發送到對應的叢集節點。降低了用戶端的複雜度，需要proxy收集叢集節點資訊。Twemproxy是twitter開源的，實現這一功能的proxy.這個實現方式在用戶端和伺服器之間加了一個proxy，

但這是在redis 3.0穩定版本出來之前官方推薦的方式。結合redis-sentinel的HA方案，是個不錯的組合。

Redis 實踐之叢集方案