一、 方案

1. 介紹
redis集群分為服務端集群（Cluster）和客戶端分片（Sharding）
服務端集群：redis3.0以上版本實現，使用哈希槽，計算key的CRC16結果再模16834。此處暫不介紹
客戶端分片：3.0以下使用，采用Key的一致性hash算法來區分key存儲在哪個Redis實例上。每個Redis實例彼此獨立，使用ShardedJedisPool

2. Sharding存在兩個問題

單點故障問題：當集群中的某一臺服務掛掉之后，客戶端在根據一致性hash無法從這臺服務器獲取數據。對于單點故障問題，我們可以使用Redis的HA高可用來實現。利用Redis-Sentinal來通知主從服務的切換。
擴容問題：因為使用了一致性哈稀進行分片，那么不同的key分布到不同的Redis-Server上，當我們需要擴容時，需要增加機器到分片列表中，這時候會使得同樣的key算出來落到跟原來不同的機器上，這樣如果要取某一個值，會出現取不到的情況，之前的緩存相當于全部失效。對于擴容問題，Redis的作者提出了一種名為Pre-Sharding的方式。即事先部署足夠多的Redis服務。

3. 一致性hash算法（Consistent hashing）

環形hash空間，早在1997年就在論文《Consistent hashing and random trees》提出
虛擬節點（解決hash傾斜性，多些虛擬節點）
命中率計算公式：(1-n/(n+m)*100% （n：服務器數，m：新增的服務器數）

二、 Sharding解決辦法

1. 單點故障問題解決：
　　使用Redis主從復制的功能，兩臺物理主機上分別都運行有Redis-Server，其中一個Redis-Server是另一個的從庫，采用雙機熱備技術，客戶端通過虛擬IP訪問主庫的物理IP，當主庫宕機時，切換到從庫的物理IP。只是事后修復主庫時，應該將之前的從庫改為主庫（使用命令slaveof no one），主庫變為其從庫（使用命令slaveof IP PORT），這樣才能保證修復期間新增數據的一致性。

2. 通過pre-sharding進行Redis在線擴容。

　　解決動態擴容和數據分區的問題，實際就是在同一臺機器上部署多個Redis實例的方式，當容量不夠時將多個實例拆分到不同的機器上，這樣實際就達到了擴容的效果。Pre-Sharding方法是將每一個臺物理機上，運行多個不同端口的Redis實例，假如有三個物理機，每個物理機運行三個Redis實例，那么我們的分片列表中實際有9個Redis實例，當我們需要擴容時，增加一臺物理機來代替9個中的一個redis，有人說，這樣不還是9個么，是的，但是以前服務器上面有三個redis，壓力很大的，這樣做，相當于單獨分離出來并且將數據一起copy給新的服務器。值得注意的是，還需要修改客戶端被代替的redis的IP和端口為現在新的服務器，只要順序不變，不會影響一致性哈希分片。
拆分過程如下：

在新機器上啟動好對應端口的Redis實例。
配置新端口為待遷移端口的從庫。
待復制完成，與主庫完成同步后，切換所有客戶端配置到新的從庫的端口。
配置從庫為新的主庫。
移除老的端口實例。
重復上述過程遷移好所有的端口到指定服務器上。

以上拆分流程是Redis作者提出的一個平滑遷移的過程，不過該拆分方法還是很依賴Redis本身的復制功能的，如果主庫快照數據文件過大，這個復制的過程也會很久，同時會給主庫帶來壓力。所以做這個拆分的過程最好選擇為業務訪問低峰時段進行。

三、實現

打開redis.conf，修改端口號，避免端口沖突
啟動多個Redis實例，每個Redis彼此獨立
使用RedisShardedPool增加多個Redis

總結

以上是生活随笔為你收集整理的Redis搭建（四）：Sharding集群模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。