實驗環境：
server1 172.25.254.1
server2 172.25.254.2
server3 172.25.254.3
簡介
Redis Sentinel是Redis官方的高可用性解決方案。
Redis 的 Sentinel 系統用於管理多個 Redis 服務器（instance）， 該系統執行以下三個任務：
- 監控（Monitoring）： Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。
- 提醒（Notification）： 當被監控的某個 Redis 服務器出現問題時， Sentinel 可以通過 API
向管理員或者其他應用程序發送通知。 - 自動故障遷移（Automatic failover）： 當一個主服務器不能正常工作時， Sentinel 會開始一次自動故障遷移操作，它會將失效主服務器的其中一個從服務器升級爲新的主服務器， 並讓失效主服務器的其他從服務器改爲複製新的主服務器；當客戶端試圖連接失效的主服務器時， 集羣也會向客戶端返回新主服務器的地址， 使得集羣可以使用新主服務器代替失效服務器。
Redis Sentinel 是一個分佈式系統， 你可以在一個架構中運行多個 Sentinel 進程（progress）， 這些進程使用流言協議（gossip protocols)來接收關於主服務器是否下線的信息， 並使用投票協議（agreement protocols）來決定是否執行自動故障遷移， 以及選擇哪個從服務器作爲新的主服務器。
雖然 Redis Sentinel 釋出爲一個單獨的可執行文件 redis-sentinel ， 但實際上它只是一個運行在特殊模式下的 Redis 服務器， 你可以在啓動一個普通 Redis 服務器時通過給定 –sentinel 選項來啓動 Redis Sentinel 。
獲取Sentinel
Sentinel 程序可以在編譯後的 src 文檔中發現， 它是一個命名爲 redis-sentinel 的程序。
用cp命令，將sentinel的配置文件複製到三臺主機的 /etc/redis/下：
cp sentinel.conf /etc/redis/
啓動Sentinel
redis-server /path/to/sentinel.conf --sentinel
主觀下線和客觀下線
-
主觀下線（Subjectively Down， 簡稱 SDOWN）指的是單個 Sentinel 實例對服務器做出的下線判斷。
-
客觀下線（Objectively Down， 簡稱 ODOWN）指的是多個 Sentinel 實例在對同一個服務器做出 SDOWN 判斷，並且通過 SENTINEL is-master-down-by-addr 命令互相交流之後， 得出的服務器下線判斷。 （一個Sentinel 可以通過向另一個 Sentinel 發送 SENTINEL is-master-down-by-addr
命令來詢問對方是否認爲給定的服務器已下線。）
配置
server1 2 3 中配置哨兵;
vim /etc/redis/sentinel.conf
其中做的更改爲
protected-mode no 不開啓保護
sentinel monitor mymaster 172.25.254.1 6379 2 監控本機的6379端口，2代表有兩個投票時纔可以作爲master主機
sentinel down-after-milliseconds mymaster 10000 當master主機掛掉了隔10s會進行切換master
server2 和server3 ，我們都設置爲server1的slave結點:
vim /etc/redis/6379.conf
測試：
在三臺主機中都啓動sentinel
redis-server /etc/redis/sentinel.conf --sentinel
打開後是這個樣子的:
可以看到當前的master和兩個slave。還有兩個哨兵，server1是server2和3，2是1和3，3是1和2.
我們在server1中進入 redis-cli 命令行，連接6379 端口，執行 info 命令
就可以看到：
看到複製的信息。
我們連接26379端口，查看哨兵信息：
redis-cli -p 26379
有兩個slave，三個哨兵，因爲我們三個結點都打開了哨兵。
我們現在關閉server1的redis，觀察server2和server3如何產生新的master，這裏需要等待10s，由於我們前面的設定。
server2中：
可以看出，server2已經成爲了新的master。切換成功。
而且只有一個slave 是server3。
server3中;
它時slave結點，matser是server2.
現在恢復server1的redis：
/etc/init.d/redis_6379 start
它會自動變成slave結點加入到server2的matser中。
集羣
概念
Redis 集羣是一個提供在多個Redis間節點間共享數據的程序集。
Redis集羣並不支持處理多個keys的命令,因爲這需要在不同的節點間移動數據,從而達不到像Redis那樣的性能,在高負載的情況下可能會導致不可預料的錯誤.
Redis 集羣通過分區來提供一定程度的可用性,在實際環境中當某個節點宕機或者不可達的情況下繼續處理命令.
Redis 集羣的優勢:
- 自動分割數據到不同的節點上。
- 整個集羣的部分節點失敗或者不可達的情況下能夠繼續處理命令。
配置部署
我們先關閉前面開啓的哨兵和redis。
server1 中
mkdir /usr/local/rediscluster 建立集羣目錄
[root@server1 rediscluster]# mkdir 700{1..6} 建立6個結點目錄（示例）
[root@server1 rediscluster]# ls
7001 7002 7003 7004 7005 7006
在七個目錄中都寫一個配置文件（按序號替換）：
cd 7001
vim redis.conf
port 7001
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
pidfile "/usr/local/rediscluster/7001/redis.pid"
logfile "/usr/local/rediscluster/7001/redis.log"
daemonize yes
dir "/usr/local/rediscluster/7001"
然後我們就可以打開redis了：
[root@server1 7001]# redis-server redis.conf
依次打開：
端口打開。
[root@server1 7001]# redis-cli -p 7001
127.0.0.1:7001> info
集羣已經打開。
創建集羣
server1 中：
用help查詢集羣的搭建
redis-cli --cluster create --cluster-replicas 1 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006
cluster-replicas 是創建複製結點，我們當前有8個結點，所以應該是三主三從。
以M開頭的就是master結點，並分配16384個哈希槽，
我們用7001的登陸redis：
[root@server1 src]# redis-cli -c -p 7001
127.0.0.1:7001> set name westos
-> Redirected to slot [5798] located at 127.0.0.1:7002
OK
我們設置變量時就會從及羣衆自動重定向到7002上的5798槽上。
我們在 7003 上訪問時
[root@server1 src]# redis-cli -c -p 7003
127.0.0.1:7003> get name
-> Redirected to slot [5798] located at 127.0.0.1:7002
"westos"
就會自動跳轉到7002上。
7002當前是master，我們掛掉它測試高可用是否能生效：
127.0.0.1:7002> SHUTDOWN 掛掉7002
not connected>
[root@server1 ~] redis-cli --cluster info 127.0.0.1:7001
Could not connect to Redis at 127.0.0.1:7002: Connection refused
127.0.0.1:7001 (da2992a7...) -> 0 keys | 5461 slots | 1 slaves.
127.0.0.1:7004 (c1f385c9...) -> 1 keys | 5462 slots | 0 slaves.
127.0.0.1:7003 (3cb02773...) -> 0 keys | 5461 slots | 1 slaves.
[OK] 1 keys in 3 masters.
0.00 keys per slot on average.
可見7004當前就接替7002作爲了master了，它沒有slave.
此時我們還可以獲取到值：
因爲7002 和7004 是主從關係。
但當我們在掛掉7004 時：
就獲取不到值了，因爲它存儲在第5798個哈希槽上。他還告訴我們集羣已經掛了。
這樣的集羣性能就不是很高了，這也是redis不被廣泛應用的弊端。
這就是保存在7002上面的建值對。
我們在開啓剛纔掛掉的7002 7004：
就又可以看到值了。