壹、Redis主從分離
准備三個redis配置文件（redis.conf），分別修改為redis6380.conf、redis6381.conf、redis6382.conf
一、配置Master
1、修改端口
# Accept connections on the specified port, default is 6379 (IANA #815344). # If port 0 is specified Redis will not listen on a TCP socket. port 6380
redis 的默認端口是6379，這里我們把主服務器的端口設置為6380
2、修改pidfile
# If a pid file is specified, Redis writes it where specified at startup # and removes it at exit. # # When the server runs non daemonized, no pid file is created if none is # specified in the configuration. When the server is daemonized, the pid file # is used even if not specified, defaulting to "/var/run/redis.pid". # # Creating a pid file is best effort: if Redis is not able to create it # nothing bad happens, the server will start and run normally. pidfile /var/run/redis_6380.pid
pidfile 是我們啟動redis 的時候，linux 為我們分配的一個pid 進程號，如果這里不作修改，會影響后面redis服務的啟動
二、配置Slave
和上面配置 master一樣，我們需要修改端口號和pid 文件，分別為6380和6381，在修改完之后，有兩種方法配置從服務
1、在配置文件中配置從服務
先修改6381的配置
################################# REPLICATION ################################# # # slaveof <masterip> <masterport>
slaveof 127.0.0.1 6380
可以在配置文件中直接修改 slaveof 屬性，我們直接配置主服務器的ip 地址，和端口號，如果這里主服務器有配置密碼
可以通過配置masterauth 來設置鏈接密碼
# If the master is password protected (using the "requirepass" configuration # directive below) it is possible to tell the slave to authenticate before # starting the replication synchronization process, otherwise the master will # refuse the slave request. # # masterauth <master-password>
啟動redis 服務：
可以看到，現在有兩個現在在運行，分別進入6380、6381的客戶端，看一下狀態
可看到主從的信息，6381是個從服務的角色，連着主服務6380
2、在服務啟動后設置
修改6382端口的服務器配置文件之后，啟動服務
進入6382客戶端，查看當前服務狀態
可以看到，當前服務器的狀態時作為一個主服務的角色在運行，我們接下來修改他的狀態，在其客戶端使用命令 ：slaveof 127.0.0.1 6380
修改后，查看其狀態，其作為6380的一個從服務
接下來，查看目前master(6380)服務的狀態，其從服務變為6381和6382
可以看到，兩個從服務已經在連着主服務器，上面兩種配置的區別在於，當salve 斷線重連之后，
如果我們是修改類配置文件，重連之后會自己鏈接上去master，並且同步master 上面的數據，
如果我們是手動連接上去的主服務器，重連之后，從服務器會讀取自己本地的 rdb 回復數據，而不會去自動鏈接主服務
在master上插入鍵值數據后在slave上可以獲取到，主從同步正常，slave上只能查看，不能進行寫操作，以免破壞數據的一致性
三、總結
如果在主從復制架構中出現宕機的情況，需要分情況看：
1、 從Redis宕機
這個相對而言比較簡單，在Redis中從庫重新啟動后會自動加入到主從架構中，自動完成同步數據；
2、 主Redis宕機
a) 這個相對而言就會復雜一些，需要以下2步才能完成
i. 第一步，在從數據庫中執行SLAVEOF NO ONE命令，斷開主從關系並且提升為主庫繼續服務；
ii. 第二步，將主庫重新啟動后，執行SLAVEOF命令，將其設置為其他庫的從庫，這時數據就能更新回來；
b) 這個手動完成恢復(人工介入)的過程其實是比較麻煩的並且容易出錯，有沒有好辦法解決呢？當前有的，Redis提供的哨兵（sentinel）的功能。
貳、Sentinel 哨兵
redis的哨兵機制是redis2.8開始支持，而集群模式是redis3.0開始支持。
redis的sentinel系統用於管理多個redis服務器，該系統主要執行三個任務：監控、提醒、自動故障轉移。
1、監控（Monitoring）： Redis Sentinel實時監控主服務器和從服務器運行狀態，並且實現自動切換。
2、提醒（Notification）：當被監控的某個 Redis 服務器出現問題時， Redis Sentinel 可以向系統管理員發送通知， 也可以通過 API 向其他程序發送通知。
3、自動故障轉移（Automatic failover）： 當一個主服務器不能正常工作時，Redis Sentinel 可以將一個從服務器升級為主服務器， 並對其他從服務器進行配置，讓它們使用新的主服務器。當應用程序連接Redis 服務器時， Redis Sentinel會告之新的主服務器地址和端口。
1、配置端口
在sentinel.conf 配置文件中， 我們可以找到port 屬性，這里是用來設置sentinel 的端口，一般情況下，至少會需要三個哨兵對redis 進行監控，我們可以通過修改端口啟動多個sentinel 服務。
3個sentinel節點(sentinel-26380.conf、sentinel-26381.conf、sentinel-26382.conf)的部署方法完全是一致的(端口不同),下面以sentinel-26380.conf節點的部署為例子
# port <sentinel-port> # The port that this sentinel instance will run on port 26380
2、配置主服務器的ip 和端口
我們把監聽的端口修改成6380，並且加上權值為2，這里的權值，是用來計算我們需要將哪一台服務器升級升主服務器
3、啟動Sentinel
啟動redis-sentinel 程序， 可以用redis提供的命令來啟動：./redis-sentinel sentinel-26380.conf &
可進入redis的各自客戶端使用命令info replication 查看服務狀態
4、關閉Master
手動關閉Master之后，sentinel 在監聽master 確實是斷線了之后，將會開始計算權值，然后重新分配主服務器
可以看到，6380主服務器斷了之后，sentinel 幫我們選了6382作為新的主服務器
進到6382的客戶端，查看狀態：
可以看到 6382，從slave 榮升為master
原本的沒有權限寫，也得到了相應的權限
5、重連Master
如果master 重連之后，會不會搶回屬於他的位置，答案是否定的，因此當master 回來之后，他也只能當個從服務
啟動原master 6380，查看其狀態，是作為6382的從服務的存在
6.Sentinel 總結
一、Sentinel的作用：
1)、Master 狀態監測
2)、如果Master 異常，則會進行Master-slave 轉換，將其中一個Slave作為Master，將之前的Master作為Slave
3)、Master-Slave切換后，master_redis.conf、slave_redis.conf和sentinel.conf的內容都會發生改變，即master_redis.conf中會多一行slaveof的配置，sentinel.conf的監控目標會隨之調換
二、Sentinel的工作方式:
1)：每個Sentinel以每秒鍾一次的頻率向它所知的Master，Slave以及其他 Sentinel 實例發送一個 PING 命令
2)：如果一個實例（instance）距離最后一次有效回復 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 則這個實例會被 Sentinel 標記為主觀下線。
3)：如果一個Master被標記為主觀下線，則正在監視這個Master的所有 Sentinel 要以每秒一次的頻率確認Master的確進入了主觀下線狀態。
4)：當有足夠數量的 Sentinel（大於等於配置文件指定的值）在指定的時間范圍內確認Master的確進入了主觀下線狀態， 則Master會被標記為客觀下線
5)：在一般情況下， 每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有Master，Slave發送 INFO 命令
6)：當Master被 Sentinel 標記為客觀下線時，Sentinel 向下線的 Master 的所有 Slave 發送 INFO 命令的頻率會從 10 秒一次改為每秒一次
7)：若沒有足夠數量的 Sentinel 同意 Master 已經下線， Master 的客觀下線狀態就會被移除。
若 Master 重新向 Sentinel 的 PING 命令返回有效回復， Master 的主觀下線狀態就會被移除。