接觸redis已經有了兩個年頭，雖然對業務上的使用已經很熟悉，但是對于redis高性能高可用方面的了解還不夠深入，是以逐漸開始學習reids搭建主從和叢集。
今天開始介紹的是最簡單的主從搭建，廢話不多說，開始了～
首先講一下主從的架構，和mysql的主從一樣，redis的主從也是從節點同步主節點的資料。我們介紹的這個主從是一主多從的架構，即是一個主節點，多個從節點，一般我們至少需要兩個從節點來實作，因為一般的資料庫對讀的壓力比較大，是以從節點會需要的多。主節點負責寫入，然後從節點負責讀出，讀寫分離。多個從節點也會分擔讀的壓力。
我們接下來會在一台機器上啟動多個三個redis執行個體，一主兩從。
redis-server --port 6379 啟動master
redis-server --port 6380 --slaveof 127.0.0.1 6379 啟動從一
redis-server --port 6381 --slaveof 127.0.0.1 6379 啟動從二
這樣我們的主從伺服器就搭建好了，我們可以測試試試。
我們可以在master中寫入資料，和讀取資料，但是在從slave隻能讀，不能寫。而且我們能夠看到主節點寫入的資料在從幾點都可以讀取到，這就是主從想要達到的效果。
但是如果master當機了怎麼辦呢？這就造成了資料沒法寫入，造成了資料的丢失，這就需要有一個slave站出來，承擔寫入的責任，也就是它要升為master，相對其他的slave也必須以它為主，來同步資料。這個我們可以通過人工來實作，但是在真是的業務場景中，我們不能可能實時去監控master，一旦master挂掉，人工的處理防方式速度慢，很大可能造成資料的丢失。這就用到了“哨兵”。
Redis Sentinel是一個分布式架構，包含若幹個Sentinel節點和Redis資料節點，每個Sentinel節點會對資料節點和其餘Sentinel節點進行監控，當發現節點不可達時，會對節點做下線辨別。如果被辨別的是主節點，他還會選擇和其他Sentinel節點進行“協商”，當大多數的Sentinel節點都認為主節點不可達時，他們會選舉出一個Sentinel節點來完成自動故障轉移工作，同時将這個變化通知給Redis應用方。整個過程完全自動，不需要人工介入，是以可以很好解決Redis的高可用問題。
下面這張圖很好的描述了這種監控的關系，這張圖是從網上找的，太懶了，不像想畫了：
其實每個sentinel是有互相監控的，并不是隻監控其他的資料節點。
redis-sentinel.conf檔案一般存在redis安裝目标錄下，由于我們需要在同一台機器部署多個，是以我們需要使用不同的端口。redis-sentinel的端口預設是26379，很好記，redis的預設端口6379+20000。以此類推我們啟動三個redis-sentinel的端口分别是26379、26380、26381。這個我們需要在redis-sentinel.conf中修改。以下是配置檔案：
// Sentinel節點的端口
port 26379
dir /var/redis/data/
logfile "26379.log"
// 目前Sentinel節點監控 127.0.0.1:6379 這個主節點
// 2代表判斷主節點失敗至少需要2個Sentinel節點節點同意
// mymaster是主節點的别名
sentinel monitor mymaster 127.0.0.1 6379 2
//每個Sentinel節點都要定期PING指令來判斷Redis資料節點和其餘Sentinel節點是否可達，如果超過30000毫秒且沒有回複，則判定不可達
sentinel down-after-milliseconds mymaster 30000
//當Sentinel節點集合對主節點故障判定達成一緻時，Sentinel上司者節點會做故障轉移操作，選出新的主節點，原來的從節點會向新的主節點發起複制操作，限制每次向新的主節點發起複制操作的從節點個數為1
sentinel parallel-syncs mymaster 1
//故障轉移逾時時間為180000毫秒
sentinel failover-timeout mymaster 180000
我們這樣命名sentinel-26379.conf、sentinel-26380.conf、sentinel-26381.conf
接下來啟動：
redis-sentinel sentinel-26379.conf、redis-sentinel sentinel-26380.conf、redis-sentinel sentinel-26381.conf
這樣哨兵就可以正常工作啦～當我們把master的程序kill掉的時候會發現，會有slave變成了master，多麼神奇～