背景說明：
這里采用1主2從的redis集群，3個sentinel搭建高可用redis集群。
一，關於搭建redis-sentinel高可用之前，我們必須要了解redis主從搭建redis-sentinel的基礎。
redis-sentinel功能：
- 監控：哨兵不斷的檢查master和slave是否正常的運行。
- 通知：當監控的某台Redis實例發生問題時，可以通過API通知系統管理員和其他的應用程序。
- 自動故障轉移：如果一個master不正常運行了，哨兵可以啟動一個故障轉移進程，將一個slave升級成為master，其他的slave被重新配置使用新的master，並且應用程序使用Redis服務端通知的新地址。
- 配置提供者：哨兵作為Redis客戶端發現的權威來源：客戶端連接到哨兵請求當前可靠的master的地址。如果發生故障，哨兵將報告新地址。
二， redis主從安裝
詳情見
https://www.cnblogs.com/lin1/p/10403333.html
三，安裝redis-sentinel , 我這邊3個節點都是在一台服務器上。
cd /usr/local/src
wget http://download.redis.io/releases/redis-3.0.7.tar.gz
tar -zxvf redis-3.0.7.tar.gz
cd redis-3.0.7
make
make PREFIX=/usr/local/redis-3.0.7 install
ln -s /usr/local/redis-3.0.7 /usr/local/redis
mkdir -p /usr/local/redis/conf
cp sentinel.conf /usr/local/redis/conf/sentinel-26379.conf (復制源碼中的哨兵配置文件)
mkdir -p /usr/local/redis/logs
vim /usr/local/redis/conf/sentinel-26379.conf ，改成如下： 10.211.55.7是redis的主，mymaster是隨意取的名字
port 26379 dir "/tmp" logfile "/usr/local/redis/logs/sentinel-26379.log" daemonize yes sentinel monitor mymaster 10.211.55.7 6379 2 sentinel auth-pass mymaster linlin sentinel down-after-milliseconds mymaster 15000 sentinel failover-timeout mymaster 120000 sentinel parallel-syncs mymaster 1 #發生切換之后執行的一個自定義腳本：如發郵件、vip切換等 #sentinel notification-script <master-name> <script-path>
vim /usr/local/redis/conf/sentinel-26380.conf
port 26380 dir "/tmp" logfile "/usr/local/redis/logs/sentinel-26380.log" daemonize yes sentinel monitor mymaster 10.211.55.7 6379 2 sentinel down-after-milliseconds mymaster 15000 sentinel failover-timeout mymaster 120000 sentinel auth-pass mymaster linlin sentinel config-epoch mymaster 0 #發生切換之后執行的一個自定義腳本：如發郵件、vip切換等 #sentinel notification-script <master-name> <script-path>
vim /usr/local/redis/conf/sentinel-26381.conf
port 26381 dir "/tmp" logfile "/usr/local/redis/logs/sentinel-26381.log" daemonize yes sentinel monitor mymaster 10.211.55.7 6379 2 sentinel down-after-milliseconds mymaster 15000 sentinel failover-timeout mymaster 120000 sentinel auth-pass mymaster linlin sentinel config-epoch mymaster 0 #發生切換之后執行的一個自定義腳本：如發郵件、vip切換等 #sentinel notification-script <master-name> <script-path>
三，啟動redis-sentinel
cd /usr/local/redis/bin
./redis-sentinel ../conf/sentinel-26379.conf
./redis-sentinel ../conf/sentinel-26380.conf
./redis-sentinel ../conf/sentinel-26381.conf
啟動之后 sentinel節點的配置文件，會默認生成部分配置段，該配置段其實就是標注從節點和master節點已經sentinel節點的。
當然，如果發生故障轉移，redis中的配置也會發生變化。
四，查看日志，簡單分析
sentinel-26379的日志，其他節點類似，這也是我們為什么沒在redis-sentinel節點中配置從節點和其他sentinel節點的原因。他們會通過消息訂閱進行數據交換。
五，模擬故障，查看故障是否轉移
master端自動down掉，為此，這邊直接使用kill命令演示。
master端：已經kill掉master端進程
查看日志：
master(6379)端日志： 無日志生成
slalve1 (6380)端日志：
丟失連接，放棄原先儲存的master信息，並嘗試繼續連接，但是一直被拒絕。拒絕的時間31s,進行故障轉移的時間為47s,故障轉移完成時間為48s。（為啥這么快，其實跟我redis沒有數據有很大關系 哈哈）
slave2 (6381)端日志：
sentinel-26379端日志：
sentinel-26380端日志：
sentinel-26381端日志:
從上述日志可以發現，故障已經轉移，10.211.55.7 6381已經成為新的master,而原先的6379已經被下線了，但是仍然被關注中。
登陸最新的master端查看：
上述，就是故障轉移成功了。接下來我們啟動最早的master，查看是否會重新加入到redis集群中。
如下，可以發現原先的master,已經成為slave了。
以上，就是redis sentinel集群搭建的過程。測試過，如果一個sentinel掛掉，自動轉移還是可以的哦。