目錄
1. 什么是哨兵模式
哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的進程，作為進程，它會獨立運行。其原理是哨兵通過發送命令，等待Redis服務器響應，從而監控運行的多個Redis實例
2. Redis哨兵集群（功能，作用）
1. 監控（Monitoring）：哨兵（sentinel）會不斷地檢查你的master和slave是否運作正常
2. 提醒（Notification）：當被監控的某個redis出問題時，哨兵可以通過API向管理員或者其他應用程序發送通知
3. 自動故障遷移（Automatic failover）：當一個master不能正常工作時，哨兵（sentinel）會開始一次自動故障遷移操作，它會將失效master的其中一個slave升級為新的master
3. Redis重點闡述容災機制
當某個master服務下線時，所有的slave將無法同步數據，這對於redis集群就是災難性的，此時哨兵自動將該master下的某個slave服務升級為master服務器替代已下線的master服務繼續處理請求，這時災難的局面就被扭轉了回來，這就是容災機制
4. Redis哨兵-原理
5. Redis-sentinel集群
1、sentinel作用
1. 當用Redis做主從方案時，假如master宕機，Redis本身無法自動進行主備切換
2. 而Redis-sentinel本身也是一個獨立運行的進程，它能監控多個master-slave集群，發現master宕機后能進行自動切換。
2、sentinel原理
1. sentinel負責持續監控主節點的健康，當主節掛掉時，自動選擇一個最優的從節點切換成主節點 2. 從節點來連接集群時會首先連接sentinel，通過sentinel來查詢主節點的地址 3. 當主節點發生故障時，sentinel會將最新的主節點地址告訴客戶端，可以實現無需重啟自動切換redis
3、sentinel支持集群
1. 只使用單個sentinel進程來監控redis集群是不可靠的，當sentinel進程宕掉后sentinel本身也有單點問題
2. 如果有多個sentinel，redis的客戶端可以隨意地連接任意一個sentinel來獲得關於redis集群中的信息。
4、sentinel版本
1. Sentinel當前穩定版本稱為Sentinel 2，Redis2.8和Redis3.0附帶穩定的哨兵版本
2. 安裝完redis-3.2.8后，redis-3.2.8/src/redis-sentinel啟動程序 redis-3.2.8/sentinel.conf是配置文件。
5、運行sentinel兩種方式（效果相同）
- 法1：redis-sentinel /path/to/sentinel.conf
- 法2：redis-server /path/to/sentinel.conf --sentinel
1. 以上兩種方式，都必須指定一個sentinel的配置文件sentinel.conf，如果不指定，將無法啟動sentinel。
2. sentinel默認監聽26379端口，所以運行前必須確定該端口沒有被別的進程占用。
6、sentinel.conf配置文件說明
1. 配置文件只需要配置master的信息就好啦，不用配置slave的信息，因為slave能夠被自動檢測到 2. 需要注意的是，配置文件在sentinel運行期間是會被動態修改的，例如當發生主備切換時候，配置文件中的master會被修改為另外一個slave。 3. 這樣，之后sentinel如果重啟時，就可以根據這個配置來恢復其之前所監控的redis集群的狀態。
sentinel.conf配置文件注釋
1 '''1、sentinel monitor mymaster 127.0.0.1 6379 2''' 2 #1）sentinel監控的master的名字叫做mymaster,地址為127.0.0.1:6379 3 #2）當集群中有2個sentinel認為master死了時，才能真正認為該master已經不可用了 4 5 '''2、sentinel down-after-milliseconds mymaster 60000''' 6 #1）sentinel會向master發送心跳PING來確認master是否存活，如果master在60000毫秒內不回應PONG 7 #2）那么這個sentinel會單方面地認為這個master已經不可用了 8 9 '''3、sentinel failover-timeout mymaster 180000''' 10 #1）如果sentinel A推薦sentinel B去執行failover，B會等待一段時間后，自行再次去對同一個master執行failover， 11 #2）這個等待的時間是通過failover-timeout配置項去配置的。 12 #3）從這個規則可以看出，sentinel集群中的sentinel不會再同一時刻並發去failover同一個master， 13 #4）第一個進行failover的sentinel如果失敗了，另外一個將會在一定時間內進行重新進行failover，以此類推。 14 15 '''4、sentinel parallel-syncs mymaster 1''' 16 #1）在發生failover主備切換時，這個選項指定了最多可以有多少個slave同時對新的master進行同步 17 #2）如果這個數字越大，就意味着越多的slave因為replication而不可用，這個數字越小，完成failover所需的時間就越長。 18 #3）可以通過將這個值設為 1 來保證每次只有一個slave處於不能處理命令請求的狀態。
7、配置傳播
1. 一旦一個sentinel成功地對一個master進行了failover，它將會把關於master的最新配置通過廣播形式通知其它sentinel，其它的sentinel則更新對應master的配置。 2. 一個faiover要想被成功實行，sentinel必須能夠向選為master的slave發送SLAVE OF NO ONE命令，然后能夠通過INFO命令看到新master的配置信息。 3. 當將一個slave選舉為master並發送SLAVE OF NO ONE`后，即使其它的slave還沒針對新master重新配置自己，failover也被認為是成功了的。
因為每一個配置都有一個版本號，所以以版本號最大的那個為標准：
1 1）假設有一個名為mymaster的地址為192.168.1.50:6379。 2 3 2）一開始，集群中所有的sentinel都知道這個地址，於是為mymaster的配置打上版本號1。 4 5 3）一段時候后mymaster死了，有一個sentinel被授權用版本號2對其進行failover。 6 7 4）如果failover成功了，假設地址改為了192.168.1.50:9000，此時配置的版本號為2 8 9 5）進行failover的sentinel會將新配置廣播給其他的sentinel，發現新配置的版本號為2時，版本號變大了， 10 說明配置更新了，於是就會采用最新的版本號為2的配置。
生產環境使用docker-compose來搭建
代碼演示如下：
git clone https://gitee.com/QiHanXiBei/redis_sentinel.git
cd /home
cd redis_sentinel/
docker-compose up --force-recreate #啟動 由於我們安裝redis時設置了開機自啟，這里我們需要kill-9殺死進程
在master中連接redis------------------> redis-cli
salve1中使用6380連接redis---------> redis-cli -p 6380
salve2中使用6381連接redis---------> redis-cli -p 6381
數據同步：
master存入數據-------------------------> set 123 123
salve1和salve2獲取數據-------------------------> get 123
此時我們模擬主機宕機------------------> docker stop redis_sentinel_master_1
初始主機中我們將redis退出重連就會發現他已經連不上了
而從機中會推舉一個成為主機，我們使用info查看 
同樣還可以再進行測試，在這個從–>主（slave2）中存數據----> set 123 456
另外的從–>從（slave1）取數據—> get 123
我們可以看到數據還是同步的
6. Redis主流集群方案
1）redis cluster集群方案
2）master/slave主從方案
3）哨兵模式來進行主從替換以及故障恢復
7. codis
- 什么是codis？
1. codis是redis集群解決方案之一，codis是GO語言開發的代理中間件
2. 當客戶端向codis發送指令時，codis負責將指令轉發給后面的redis實例來執行，並將返回結果轉發給客戶端
- 為什么會出現codis？
1. 在大數據高並發場景下，單個redis實例往往會無法應對
2. 首先redis內存不易過大，內存太大會導致rdb文件過大，導致主從同步時間過長
3. 其次在CPU利用率中上，單個redis實例只能利用單核，數據量太大，壓力就會特別大
- codis部署方案
1. 單個codis代理支撐的QPS比較有限，通過啟動多個codis代理可以顯著增加整體QPS
2. 多codis還能起到容災功能，掛掉一個codis代理還有很多codis代理可以繼續服務
- codis分片原理
1. codis負責將特定key轉發到特定redis實例，codis默認將所有key划分為1024個槽位
2. 首先會對客戶端傳來的key進行crc32計算hash值，然后將hash后的整數值對1024進行取模，這個余數就是對應的key槽位
3. 每個槽位都會唯一映射到后面的多個redis實例之一，codis會在內存中維護槽位和redis實例的映射關系
4. 這樣有了上面key對應的槽位，那么它應該轉發到那個redis實例就很明確了
5. 槽位數量默認是1024，如果集群中節點較多，建議將這個數值大一些，比如2048,4096
- 不同codis槽位如何同步
1. 如果codis槽位值存在內存中，那么不同的codis實例間的槽位關系得不到同步
2. 所以codis還需要一個分布式配置存儲的數據庫專門來持久化槽位關系
3. codis將槽位關系存儲在zookeeper中，並且提供一個dashboard可以來觀察和修改槽位關系