Jedis編程設計:ShardJedis/ShardJedisPool

基於Jedis實現Redis分片的理解

http://m.blog.csdn.net/blog/wenzhibinbin_pt/22808939

 

Jedis編程設計:ShardJedis/ShardJedisPool

http://www.verydemo.com/demo_c288_i90831.html

 

Jedis分片及擴容

http://blog.csdn.net/lang_man_xing/article/details/38405269

 

1.       擴容問題：

由於使用了一致性哈稀進行分片，那麼不一樣的key分佈到不一樣的Redis-Server上，當咱們須要擴容時，須要增長機器到分片列表中，這時候會使得一樣的key算出來落到跟原來不一樣的機器上，這樣若是要取某一個值，會出現取不到的狀況，對於這種狀況，Redis的做者提出了一種名爲Pre-Sharding的方式：

Pre-Sharding方法是將每個臺物理機上，運行多個不一樣斷口的Redis實例，假若有三個物理機，每一個物理機運行三個Redis實際，那麼咱們的分片列表中實際有9個Redis實例，當咱們須要擴容時，增長一臺物理機，步驟以下：

A.     在新的物理機上運行Redis-Server；

B.      該Redis-Server從屬於(slaveof)分片列表中的某一Redis-Server（假設叫RedisA）；

C.      等主從複製(Replication)完成後，將客戶端分片列表中RedisA的IP和端口改成新物理機上Redis-Server的IP和端口；

D.     中止RedisA。

這樣至關於將某一Redis-Server轉移到了一臺新機器上。Prd-Sharding其實是一種在線擴容的辦法，但仍是很依賴Redis自己的複製功能的，若是主庫快照數據文件過大，這個複製的過程也會好久，同時會給主庫帶來壓力。因此作這個拆分的過程最好選擇爲業務訪問低峯時段進行。

 再總結一下這裏的擴容：其實這裏的擴容很簡單的思想：就是前期咱們可能只用到兩三個服務器，可是可是擔憂後期要擴容，因此前期就如今每個機器上面再裝兩個redis，這樣就有9個redis嘛，後面若是確實服務器不夠，須要擴容，就從新找一臺新機來代替9箇中的一個redis，有人說，這樣不仍是9個麼，是的，可是之前服務器上面有三個redis，壓力很大的，這樣作，至關於單獨分離出來而且將數據一塊兒copy給新的服務器。值得注意的是，還須要修改客戶端被代替的redis的IP和端口爲如今新的服務器，只要順序不變，不會影響一致性哈希分片（剛纔上面剛說了哈）。

2.       單點故障問題：

仍是用到Redis主從複製的功能，兩臺物理主機上分別都運行有Redis-Server，其中一個Redis-Server是另外一個的從庫，採用雙機熱備技術，客戶端經過虛擬IP訪問主庫的物理IP，當主庫宕機時，切換到從庫的物理IP。只是過後修復主庫時，應該將以前的從庫改成主庫（使用命令slaveof no one），主庫變爲其從庫（使命令slaveof IP PORT），這樣才能保證修復期間新增數據的一致性。