上一節實現了Redis集羣的主從模式，這一節來實現一下哨兵模式。
有了主從模式，爲什麼還會需要哨兵模式呢？
上一節我們瞭解到，爲了緩解服務器壓力，我們可以對redis的系統實現一個主從分離，一個master主要實現寫功能，一個或多個 slave 主要負責讀功能。
那麼這種模式有個什麼問題呢，
萬一我們的master 突然宕機了，不能提供寫服務了，只能依靠slave實現讀的功能，這種情況是很糟糕的。
所以爲了解決這種困境，前輩們又提出了一種解決方式，哨兵模式。
1、概念
首先介紹一下哨兵模式的大致架構，還是一主多從模式，不過我們還需要加上一個或多個能提供監測服務的哨兵（sentinel）。
這個哨兵，或者說幾個哨兵，能夠實時檢測我們的master的狀態，當master處於正常運行狀態時，一切都OK，平安夜。
一旦master出現故障，服務器宕機，內存滿了等問題導致master不能再提供服務了。
哨兵就會馬上監測到這個情況，在默認的等待時間30s後，如果master還是不能使用，那這些哨兵就會自動地從slave中間挑選一個作爲 master，重新形成一個 一主多從的局面。
1、安裝
本次模式的實現需要兩樣東西，redis 和 redis-sentinel。
Redis的安裝就不再贅述了，sudo apt-get 在線安裝即可
redis-sentinel 的安裝也是使用在線安裝：
sudo apt-get install redis-sentinel
2、集羣詳情
我這裏設置爲一主兩從，master 地址爲 192.168.31.218
兩個 slave 地址分別爲 192.168.31.220 192.168.31.222
3、redis配置
redis的配置都是在原始的 conf 文件上進行刪改，我把原文件中註釋的部分都刪掉，如下是簡潔版。
有很多參數我也不太明白是啥意思，以後有時間可以詳細看看，這次這個博客只是用來跑通哨兵模式這個功能。
Redis 的 master 配置
#/etc/redis/redis.conf
protected-mode no
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
supervised no
pidfile "/var/run/redis/redis-server.pid"
loglevel notice
logfile "/var/log/redis/redis-server.log"
databases 16
always-show-logo yes
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename "dump.rdb"
dir "/var/lib/redis"
slave-serve-stale-data yes
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
slave-priority 100
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
slave-lazy-flush no
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
aof-use-rdb-preamble no
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes
master 的配置的話，大概就只是把 protected-mode 改成 no 就行，以上是我在Ubuntu 18.04 的一個配置。
Redis 的 slave 配置
slave 的配置和主從模式一樣，在配置中指向 master 即可，在這裏我們指向的是 218。
所以在 配置末尾加上：
slaveof 192.168.31.218 6379
4、redis-sentinel 配置
在安裝完 sentinel之後，在 /etc/redis/ 文件夾下回出現一個 sentinel.conf 文件，這個就是哨兵的配置。
（以下是把原始默認配置文件的註釋刪除之後剩下的東西進行一點修改的結果）
主從哨兵的 sentinel 配置都相同：
#/etc/redis/sentinel.conf
protected-mode yes
bind 192.168.31.218 #bind值爲各個 sentinel 所在的服務器的ip
daemonize yes
pidfile "/var/run/sentinel/redis-sentinel.pid"
logfile "/var/log/redis/redis-sentinel.log"
port 26379
dir "/var/lib/redis"
sentinel myid f392d8a65d028eb65b1baa94d4f981ab539a3ceb
#這裏修改爲 master 的地址
sentinel monitor mymaster 192.168.31.218 6379 1
sentinel config-epoch mymaster 72
sentinel leader-epoch mymaster 72
其中，在
sentinel monitor mymaster 192.168.31.218 6379 1
這一行注意下，mymaster 可自定義名稱，後面跟的 ip 就是 master 的 ip，這一行 三個 sentinel 配置文件都一樣。
注意： 關於 protected-mode 的設置以及 bind 的 ip 地址，一定要看示例是怎麼設置的，然後相應改成自己的值。
因爲如果不這樣，等你測試的時候， 使 master 宕機，會發生類似 -failover-abort-not-elected master mymaster 的報錯導致 master 切換不成功。
5、集羣服務啓動
然後在三個服務器上依次通過以下命令啓動 redis 以及 sentinel 服務：
sudo service redis restart
sudo service redis-sentinel restart
在 218 服務器，也就是我們的 master 上，進入 redis 的交互界面，
輸入 info replication ，可以看到類似如下的信息：
可以看到它的角色 role 是作爲 master 的，也可以看到所屬的兩個 slave 的 ip 端口等信息。
選擇一個 slave 查看信息，可以看到如下信息：
其中，有 master 的 ip 和端口信息，
有連接到 master 的 狀態 master_link_status 是 up，
如果 master 宕機了，則會變成 down。
master_link_status:up
6、測試宕機
當我們把 master 的 redis 關閉，那麼哨兵會在等待默認時間 30s 之後，確認 master 宕機之後，將這兩個slave 中自動選擇一個作爲 master。
這其中，有一個主觀下線和客觀下線的概念。
大致意思是，當一個 sentinel 確認 master 宕機，則稱爲主觀下線，
當所有 sentinel 都表示聯繫不上 master時，這個時候就稱爲客觀下線。
接下來，我們來通過以下命令關閉 218 master 的 redis：
sudo service redis stop
在 30s 內隨機選擇一個 slave，輸入 info replication，查看集羣狀態，
可以看到大致信息如下：
在這裏，可以看到 master_link_status 這個狀態變成了 down，表示 master 連接不上了。
然後有一行參數 可以注意下：
master_link_down_since_seconds: 4
這個表示，與master失聯的時間。
默認的時間爲 30s，在這之後，哨兵們會自動在剩下的 slave 中挑選一個作爲 master。
這個過程是不需要人爲控制的，全部由哨兵自動完成。
…
…
…
好，30s 過去了，我們再來看看這個 slave 的信息，大致信息如下：
可以看到，哨兵已經把這個 redis 自動設置爲了 master，然後 222 這個 slave 也自動變成了 新的 master 的 slave。
一朝天子一朝臣，現在所有的 slave 都會指向 新的 master，也就是測試中的 220 服務器。
注意： 看到這裏，你可能會想，slaveof 這個參數的信息是在 redis.conf 文件裏面寫好的啊，爲什麼會變呢？
沒錯，哨兵會自動更改 redis.conf 文件，把仍然是 slave 的redis的 master 指向變成了新的 master 地址。
不信你可以去看看 redis.conf 這一行，slaveof 這個參數的值已經被自動篡改了。
那麼這一步大概就是我們哨兵模式功能的一個配置以及演示過程，上面的參數配置是在我三個Ubuntu系統上完全跑通的一個實例。
如果你看到這裏，然後自己配置之後還是不能實現 master 的自動切換，不妨把我的配置整體複製過去，然後再試一下。
7、最後再多測試一步
如果開始宕機的 master 218 在 30s之後，也就是 slave 中已經重新選出了一個新的 master之後，
這時候再把原來的 master，也就是218的 redis 啓起來，那麼218 還會不會是master呢？
答案是，不會！
原來的master， 也就是 218，起來後，哨兵也會修改他的配置，把它變成一個新的 slave，加入這個集羣。
你以前是老大，但後來你失勢了，又想重新當老大，不好意思，不行的，沒辦法，只能重新當個slave，慢慢熬吧。
以上全部就是使用 Redis 搭建一個 哨兵模式（sentinel）的全過程，其中包含了，我在服務器上跑通過的 redis.conf 和 sentinel.conf 實例。
接下來的話，感覺 redis.conf 以及 sentinel.conf 中的很多參數還可以再好好研究一下。