1.1 集群的概念
所謂的集群，就是通過添加服務器的數量，提供相同的服務，從而讓服務器達到一個穩定、高效的狀態。
1.1.1 使用redis集群的必要性
問題：我們已經部署好了redis，並且能啟動一個redis，實現數據的讀寫，為什么還要學習redis集群？
答：（1）單個redis存在不穩定性。當redis服務宕機了，就沒有可用的服務了。
（2）單個redis的讀寫能力是有限的。
總結：redis集群是為了強化redis的讀寫能力。
1.1.2 如何學習redis集群
--說明：（1）redis集群中，每一個redis稱之為一個節點。
（2）redis集群中，有兩種類型的節點：主節點(master)、從節點(slave)。
（3）redis集群，是基於redis主從復制實現。
所以，學習redis集群，就是從學習redis主從復制模型開始的。
1 redis主從復制
1.1 概念
主從復制模型中，有多個redis節點。
其中，有且僅有一個為主節點Master。從節點Slave可以有多個。
只要網絡連接正常，Master會一直將自己的數據更新同步給Slaves，保持主從同步。
|
1.1 特點
（1）主節點Master可讀、可寫.
（2）從節點Slave只讀。（read-only）
因此，主從模型可以提高讀的能力，在一定程度上緩解了寫的能力。因為能寫仍然只有Master節點一個，可以將讀的操作全部移交到從節點上，變相提高了寫能力。
1.1 基於配置實現
1.1.1 需求
| 主節點 |
6380 |
| 從節點（兩個） |
6381、6382 |
1.1.2 配置步驟
（1）在/usr/local目錄下，創建一個/redis/master-slave目錄
| [root@node0719 local]# mkdir -p redis/master-slave |
（2）在master-slave目錄下，創建三個子目錄6380、6381、6382
| [root@node0719 master-slave]# mkdir 6380 6381 6382 |
（3）依次拷貝redis解壓目錄下的redis.conf配置文件，到這三個子目錄中。
| [root@node0719 master-slave]# cp /root/redis-3.2.9/redis.conf ./6380/ [root@node0719 master-slave]# cp /root/redis-3.2.9/redis.conf ./6381/ [root@node0719 master-slave]# cp /root/redis-3.2.9/redis.conf ./6382/ |
（4）進入6380目錄，修改redis.conf，將port端口修改成6380即可。
| [root@node0719 master-slave]# cd ./6380 [root@node0719 6380]# vim redis.conf
|
（5）進入6381目錄，修改redis.conf，將port端口改成6381，同時指定開啟主從復制。
| [root@node0719 6380]# cd ../6381 [root@node0719 6381]# vim redis.conf
|
（6）進入6382目錄，修改redis.conf，將port端口改成6382，同時指定開啟主從復制。
| [root@node0719 6380]# cd ../6382 [root@node0719 6381]# vim redis.conf
|
1.1.1 測試
（1）打開三個xshell窗口，在每一個窗口中，啟動一個redis節點。查看日志輸出。（不要改成后台模式啟動，看不到日志，不直觀）
| [root@node0719 master-slave]# cd 6380 && redis-server ./redis.conf |
| [root@node0719 master-slave]# cd 6381 && redis-server ./redis.conf |
| [root@node0719 master-slave]# cd 6382 && redis-server ./redis.conf |
（2）另外再打開三個xshell窗口，在每一個窗口中，登陸一個redis節點
| [root@node0719 ~]# redis-cli -p 6380 |
| [root@node0719 ~]# redis-cli -p 6381 |
| [root@node0719 ~]# redis-cli -p 6382 |
（3）在主節點6380上，進行讀寫操作，操作成功
| [root@node0719 ~]# redis-cli -p 6380 127.0.0.1:6380> set user:name zs OK 127.0.0.1:6380> get user:name "zs" 127.0.0.1:6380> |
（4）在從節點6381上
讀操作執行成功，並且成功從6380上同步了數據
| [root@node0719 ~]# redis-cli -p 6381 127.0.0.1:6381> get user:name "zs" |
寫操作執行失敗。（從節點，只能讀，不能寫）
| 127.0.0.1:6381> set user:age 18 (error) READONLY You can't write against a read only slave. |
1 Sentinel哨兵模式
1.1 主從模式的缺陷
當主節點宕機了，整個集群就沒有可寫的節點了。
由於從節點上備份了主節點的所有數據，那在主節點宕機的情況下，如果能夠將從節點變成一個主節點，是不是就可以解決這個問題了呢？
答：是的，這個就是Sentinel哨兵的作用。
1.2 哨兵的任務
Redis 的 Sentinel 系統用於管理多個 Redis 服務器（instance）， 該系統執行以下三個任務：
監控（Monitoring）： Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。
提醒（Notification）： 當被監控的某個 Redis 服務器出現問題時， Sentinel 可以通過 API 向管理員或者其他應用程序發送通知。
自動故障遷移（Automatic failover）： 當一個主服務器不能正常工作時， Sentinel 會開始一次自動故障遷移操作， 它會進行選舉，將其中一個從服務器升級為新的主服務器， 並讓失效主服務器的其他從服務器改為復制新的主服務器； 當客戶端試圖連接失效的主服務器時， 集群也會向客戶端返回新主服務器的地址， 使得集群可以使用新主服務器代替失效服務器。
1.2.1 監控（Monitoring）
（1）Sentinel可以監控任意多個Master和該Master下的Slaves。（即多個主從模式）
（2）同一個哨兵下的、不同主從模型，彼此之間相互獨立。
（3）Sentinel會不斷檢查Master和Slaves是否正常。
|
1.2.2 自動故障切換（Automatic failover）
1.2.2.1 Sentinel網絡
監控同一個Master的Sentinel會自動連接，組成一個分布式的Sentinel網絡，互相通信並交換彼此關於被監視服務器的信息。下圖中，三個監控s1的Sentinel，自動組成Sentinel網絡結構。
|
疑問：為什么要使用sentinel網絡呢？
答：當只有一個sentinel的時候，如果這個sentinel掛掉了，那么就無法實現自動故障切換了。
在sentinel網絡中，只要還有一個sentinel活着，就可以實現故障切換。
1.1.1.1 故障切換的過程
（1）投票（半數原則）
當任何一個Sentinel發現被監控的Master下線時，會通知其它的Sentinel開會，投票確定該Master是否下線（半數以上，所以sentinel通常配奇數個）。
（2）選舉
當Sentinel確定Master下線后，會在所有的Slaves中，選舉一個新的節點，升級成Master節點。
其它Slaves節點，轉為該節點的從節點。
|
（1）投票 （2）選舉 |
（3）原Master重新上線
當原Master節點重新上線后，自動轉為當前Master節點的從節點。
|
（3）原master重新上線 |
1.1 哨兵模式部署
1.1.1 需求
前提：已經存在一個正在運行的主從模式。
另外，配置三個Sentinel實例，監控同一個Master節點。
1.1.2 配置Sentinel
（1）在/usr/local目錄下，創建/redis/sentinels/目錄
| [root@node0719 local]# mkdir -p redis/sentinels |
（2）在/sentinels目錄下，以次創建s1、s2、s3三個子目錄中
| [root@node0719 sentinels]# mkdir s1 s2 s3 |
（3）依次拷貝redis解壓目錄下的sentinel.conf文件，到這三個子目錄中
| [root@node0719 sentinels]# cp /root/redis-3.2.9/sentinel.conf ./s1/ [root@node0719 sentinels]# cp /root/redis-3.2.9/sentinel.conf ./s2/ [root@node0719 sentinels]# cp /root/redis-3.2.9/sentinel.conf ./s3/ |
（4）依次修改s1、s2、s3子目錄中的sentinel.conf文件，修改端口，並指定要監控的主節點。（從節點不需要指定，sentinel會自動識別）
S1哨兵配置如下：
|
S2哨兵配置如下：
|
S3哨兵配置如下：
（5）再打開三個xshell窗口，在每一個窗口中，啟動一個哨兵實例，並觀察日志輸出
| [root@node0719 sentinels]# redis-sentinel ./s1/sentinel.conf |
| [root@node0719 sentinels]# redis-sentinel ./s2/sentinel.conf |
| [root@node0719 sentinels]# redis-sentinel ./s3/sentinel.conf |
核心日志輸出：
1.1.3 測試
（1）先關閉6380節點。發現，確實重新指定了一個主節點
|
（2）再次上線6380節點。發現，6380節點成為了新的主節點的從節點。
|
1.2 結論
Sentinel哨兵模式，確實能實現自動故障切換。提供穩定的服務