㈠ redis哨兵連接報EOF
redis哨兵技術主要作用和解決的問題是：
持久化：是最簡單的高可用方法，主要作用是數據備份，即將數據存儲在硬碟，保證數據辯敬不會因進程退出而丟失。
復制：是高可用Redis的基礎，哨兵和集群都是在復制基礎上實現高可用的。
哨兵：在復制的基礎上，哨兵實現了自動化的故障恢復。缺陷是寫攜游慎操作無法負載均衡；存儲能力磨山受到單機的限制。
集群：通過集群，Redis解決了寫操作無法負載均衡，以及存儲能力受到單機限制的問題，實現了較為完善的高可用方案。
㈡ Redis哨兵（Sentinel）模式
主從切換技術的方法是：當主伺服器宕機後，需要手動把一台從伺服器切換為主伺服器，這就需要人工干預，費事費力，還會造成一段時間內服務不可用。 這不是一種推薦的方式，更多時候，我們優先考慮 哨兵模式 。
哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的進程，作為進程，它會獨立運行。其原理是 哨兵通過發送命令，等待Redis伺服器響應，從而監控運行的多個Redis實例。
這里的哨兵有兩個作用
然而一個哨兵進程對Redis伺服器進行監控，可能會出現問題，為此，我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控，這樣就形成了多哨兵模式。
用文字描述一下 故障切換（failover） 的過程。假設主伺服器宕機，哨兵1先檢測到這個結果，系統並不會馬上進行failover過程，僅僅是哨兵1主觀的認為主伺服器不可用，這個現象成為 主觀下線 。當後面的哨兵也檢測到主伺服器不可用，並且數量達到一定值時，那麼哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行failover操作。切換成功後，就會通過發布訂閱模式，讓各個哨兵把自己監控的從伺服器實現切換主機，這個過程稱為 客觀下線 。這樣對於客戶端而言，一切都是透明的。
配置3個哨兵和1主2從的Redis伺服器來演示這個過程。
首先配置Redis的主從伺服器，修改redis.conf文件如下
上述內容主要是配置Redis伺服器，從伺服器比主伺服器多一個slaveof的配置和密碼。
配置3個哨兵，每個哨兵的配置都是一樣的。在Redis安裝目錄下有一個sentinel.conf文件，一份進行修改
上述關閉了保護模式，便於測試。
有了上述的修改，我們可以進入Redis的安裝目錄的src目錄，通過下面的命令啟動伺服器和哨兵
注意啟動的順序。 首先是主機（192.168.11.128）的Redis服務進程，然後啟動從機的服務進程，最後啟動3個哨兵的服務進程。
上面是通過Jedis進行使用的，同樣也可以使用Spring進行配置RedisTemplate使用。
sentinel down-after-milliseconds配置項只是一個哨兵在超過規定時間依舊沒有得到響應後，會自己認為主機不可用。對於其他哨兵而言，並不是這樣認為。哨兵會記錄這個消息，當擁有認為主觀下線的哨兵達到sentinel monitor所配置的數量時，就會發起一次投票，進行failover，此時哨兵會重寫Redis的哨兵配置文件，以適應新場景的需要。
㈢ 訪問redis哨兵讀數據
你好，Redis哨兵
Redis的主從復制模式下,一旦主節點由於故障不能提供服務,需要人工將從節點晉升為主節點,同時還要通知應用方更新主節點地址,對於很多應用場景這種故障處理的方式是無法接受的。可喜的是Redis從2.8開始正式提供了Redis Sentinel (哨兵)架構來解決這個問題,本章會對Redis Sentinel進行詳細分析。
基本概念
名詞 邏輯結構 物理結構 主節點 Redis主服務 一個獨立的Redis進程 從節點 Redis從服務 一個獨立的Redis進程Redis數據節點 主節點和從節點 主節點和從節點的進程 Sentinel節點 監控Redis數據節點 一個獨立的Sentinel進程 Sentinel節點集合 若干個Sentinel節點的抽象組合 若干個Sentinel節點進程 Redis Sentinel Redis高可用方案Sentinel節點集合和Redis數據及誒單進程
主從復制的問題
Redis的主從復制模式可以將主節點的數據改變同步給從節點,這樣從節點就可以起到兩個作用:第一,作為主節點的一個備份,一旦主節點出了故障不可達的情況,從節點可以作為後備「頂」上來,並且保證數據盡量不丟失(主從復制是最終一致性)。 第二,從節點可以擴展主節點的讀能力,一旦主節點不能支撐住大並發量的讀操作,從節點可以在一定程度上幫助主節點分擔讀壓力。 但是主從復制也帶來了以下問題: （1）一旦主節點出現故障,需要手動將一個從節點晉升為主節點,同時需要修改應用方的主節點地址,還需要命令其他從節點去復制新的主節點,整個過程都需要人工干預。 （2）主節點的寫能力受到單機的限制。 （3）主節點的存儲能力受到單機的限制。
高可用
Redis主從復制模式下,一旦主節點出現了故障不可達,需要人工干預進行故障轉移.無論對於Redis的應用方還是運維方都帶來了很大的不便。對於應用方來說無法及時感知到主節點的變化,必然會造成一定的寫數據丟失和讀數據錯誤,甚至可能造成應用方服務不可用。對於Redis的運維方來說,整個故障轉移的過程是需要人工來介入的,故障轉移實時性和准確性上都無法得到保障，一個1主2從的Redis主從復制模式下的主節點出現故障後,是如何進行故障轉移的。 1)主節點發生故障後,客戶端(client)連接主節點失敗,兩個從節點與主節點連接失敗造成復制畝讓帆中斷。 2)如果主節點無法正常啟動,需要選出一個從節點(slave-1),對其執行slaveof no one命令使其成為新的主節點。 3)原來的從節點（slave-1）成為新的主節點後，更新應用方的主節點信息，重新啟動應用方 4)客戶端命令另一個從節點（slave-2）去復制新的主節點（new-master） 5)待原來的主節點恢復後，讓它去復制新的主節點。上述滑春處理過程就可以認為整個服務或者架構的設計不是高可用的,因為整個故障轉移的過程需要人為介入。考慮到這點,有些公司把上述流程自動化了,但是仍然存在如下問題:第一，斷節點不可達的機制是否健全和標准。第二,如果有多個從節點,怎樣保證只有一個被晉升為主節點。第三，通知客戶端新的主節點機制是否足夠強壯。Redis Sentinel正是用於解決這個問題。
Redis Sentinel的高迅雹可用性當主節點出現故障時, Redis Sentinel能自動完成故障發現和故障轉移,並通知應用方,從而實現真正的高可用。Redis Sentinel是一個分布式架構,其中包含若干個Sentinel節點和Redis數據節點,每個Sentinel節點會對數據節點和其餘Sentinel節點進行監控,當它發現節點不可達時,會對節點做下線標識。如果被標識的是主節點,它還會和其他Sentinel節點進行「協商」,當大多數Sentinel節點都認為主節點不可達時,它們會選舉出一個Sentinel節點來完成第六章sentinel.md2020/3/132 / 4自動故障轉移的工作,同時會將這個變化實時通知給Redis應用方。整個過程完全是自動的,不需要人工來介入,所以這套方案很有效地解決了Redis的高可用問題。Redis Sentinel與Redis主從復制模式只是多了若於Sentinel節點,所以Redis Sentinel並沒有針對Redis節點做了特殊處理,這里是很多開發和運維人員容易混淆的。從邏輯架構上看, Sentinel節點集合會定期對所有節點進行監控,特別是對主節點的故障實現自動轉移。假設我們現在有一個主節點，兩個從節點和三個Sentinel節點組成的Redis Sentinel的例。 整個故障轉移的處理邏輯有下面4個步驟: 1)主節點出現故障,此時兩個從節點與主節點失去連接,主從復制失敗 2)每個Sentinel節點通過定期監控發現主節點出現了故障。 3)多個Sentinel節點對主節點的故障達成一致,選舉出其中一個sentinel節點作為領導者負責故障轉移。 4)Sentinel領導者節點執行了故障轉移。通過上面介紹的Redis Sentinel邏輯架構以及故障轉移的處理,可以看出Redis Sentinl具有以下幾個功能: （1）監控: Sentinel節點會定期檢測Redis數據節點、其餘Sentinel節點是否可達。 （2）通知: Sentinel節點會將故障轉移的結果通知給應用方。 （3）主節點故障轉移:實現從節點晉升為主節點並維護後續正確的主從關系。 （4）配置提供者:在Redis Sentinel結構中,客戶端在初始化的時候連接的是Sentinel節占 集合,從中獲取主節點信息。同時看到, Redis Sentinel包含了若干個Sentinel節點,這樣做也帶來了兩個好處: （1）對於節點的故障判斷是由多個Sentinel節點共同完成,這樣可以有效地防止誤判。 （2）Sentinel節點集合是由若干個Sentinel節點組成的,這樣即使個別Sentinel節點不可用,整個Sentinel節點集合依然是健壯的。 但是Sentinel節點本身就是獨立的Redis節點,只不過它們有一些特殊,它們不存儲數據,只支持部分命令。
㈣ SpringBoot連接redis哨兵模式
設置 sentinel-26377.conf 的 protected-mode no ；默認是該欄位值是yes
修改問題[1]中為redis集群master節點的真實地址；
修改問題[2]中為 bind 0.0.0.0
【注】redisTemplate實際上是對其他嘩頌咐框架的的封裝，springboot2.x以上底層實現由jedis變為了lettuce。而且lettuce會根據櫻畝配置自動選擇是否用單機或者哨兵模式。
【1】 Redis 哨兵模式 設置密碼
【2】 sentinel搭建redis集群經驗總結
【3】SpringBoot2.x使用亂純Lettuce連接redis哨兵報錯：RedisConnectionException: Unable to connect to 127.0.0.1:16379]： https://blog.csdn.net/repAgell/article/details/106600960
【4】解決使用jedis連接是報DENIED Redis is running in protected mode錯誤： https://www.cnblogs.com/lonecloud/p/9084761.html
㈤ 已解決：客戶端無法登錄Redis伺服器報錯，解除保護模式
一：問題如下
[sql] view plain
在192.168.56.57客戶端登錄192.168.56.56的redis伺服器時，報錯如下：
[root@localhost src]# ./redis-cli -h 192.168.56.56 -p 6379 -a"aabbcc"
192.168.56.56:6379> ping
Error:Connection reset by peer
再喊行telnet一下192.168.56.56的redis伺服器的6379埠,提示redis服務有保護模式,需要解除
[root@localhost src]# telnet 192.168.56.56 6379
Trying 192.168.56.56...
Connectedto 192.168.56.56.
Escape character is '^]'.
DENIED 螞滲差Redisis running in protected modebecause protected mode is enabled, no bind address was specified, noauthentication password is requested to clients.
In this mode connections areonly accepted from the loopback interface. If you want to connect from externalcomputers to Redis you may adopt one of the following
solutions: 1) Justdisable protected mode sending the command'CONFIG SET protected-mode no' fromthe loopback interface by connecting to Redis from the same host
the server isrunning, however MAKE SURE Redisis not publicly accessible from internet ifyou do so. Use CONFIG REWRITE to make this change permanent.
2) Alternativelyyou can just disable the protected modeby editing the Redis configurationfile, and setting the protected mode option to 'no', and then restarting theserver.
3) If you started the server manually justfor testing, restart it withthe '--protected-mode no' option.
4) Setup a bind addressor an authenticationpassword. NOTE: You only need to do one of the above things in order for theserver to start accepting connections from the outside.
Connection closed by 悶皮foreign host.
二：解決方案
[sql] view plain
1、修改redis伺服器的配置文件
vi redis.conf
注釋以下綁定的主機地址
# bind 127.0.0.1
2、修改redis伺服器的參數配置
修改redis的守護進程為no ，不啟用
127.0.0.1:6379> configset daemonize "no"
OK
修改redis的保護模式為no，不啟用
127.0.0.1:6379> configset protected-mode "no"
OK
三：問題解決
[sql] view plain
再次telnet一下192.168.56.56的redis伺服器的6379埠，無問題
[root@localhost Packages]# telnet 192.168.56.56 6379
Trying 192.168.56.56...
Connectedto 192.168.56.56.
Escape character is '^]'.
再次在192.168.56.57客戶端登錄192.168.56.56的redis伺服器，無問題
[root@localhost src]# ./redis-cli -h 192.168.56.56 -p 6379 -a"aabbcc"
192.168.56.56:6379> ping
PONG
㈥ Redis哨兵模式（故障轉移測試）
哨兵模式是在主備模式的基礎上，加上哨兵，實現redis集群的故障轉移。哨兵負責監控集群狀態，當redis主節點發生故障，哨兵通過選舉，選出替代的master節點。一般需要單數的哨兵進行選舉，大多數達成一致。
問題：如果哨兵集群也有部分實例down了，出現偶數哨兵，或者只剩下一個哨兵會如何，還能進行故障轉移嗎。
為什麼會出現這個問題：哨兵其實也是redis實例，一般情況下，哨兵是為了保證redis集群的故障轉移。由於資源，以及網路通信的性能考慮，一般哨兵和redis會部署在同一物歷喚游理機。如果一台物理機出現了物理故障，哨兵實例和redis服務實例會一起down掉。
本文章針對這個問題做一下實驗。
使用3+3模式，3redis+3sentinel。
三台虛擬機，每台虛擬機運行1個redis+1個sentinel
ip、角色規劃
192.168.237.101：master，sentinel
192.168.237.100：slave，sentinel
192.168.237.103：slave，sentinel
安裝redis、redis sentinel
apt-get install redis-server
apt-get install redis-sentinel
redis-server配置修改(/etc/redis/redis.conf)
redis-server slave配置修改
啟動redis-server
/etc/init.d/redis-server restart
查看redis-server主從集群情況
修改sentinel配置(/etc/redis/sentinel.conf)
sentinel monitor mymaster 192.168.237.101 6379 2
sentinel known-slave mymaster 192.168.237.100 6379
protected-mode no
啟動sentinel
/etc/init.d/redis-sentinel start
查看redis-sentinel情況
預期：故障轉移，哨兵選舉出新的master
關掉redis-server（192.168.237.101）
查看sentinel日誌（/鏈者var/log/redis/redis-sentinel.log）
可以看到，+odown master，哨兵檢測master客觀下線
然後進行投票：vote-for-leader
選出新的master：switch-master mymaster 192.168.237.101 6379 192.168.237.103 6379
192.168.237.101的sentinel日誌：
查看redis和sentinel集群狀態，確認master變成了192.168.237.103（master host）
恢復192.168.237.101的redis-server，查看日誌，192.168.237.101轉換成slave
預期：有兩個sentinel，可能會出現，剩下兩個slave各得一票的情況，按照哨兵原理，會等待一段時間進行再選舉，直到某個slave有兩票，完肢銷成故障轉移。
經過3.1實驗，master轉換到了192.168.237.103，現在先後關掉103上的sentinel和redis-server
查看兩台sentinel的redis-sentinel日誌，可以選出master，進行故障轉移：
查看redis集群狀態，確認master（192.168.237.100）
預期：無法切換
依次關掉兩個sentinel，一個redis-server master。3.2節master轉移到了100，恢復環境後，依次關掉103,100的sentinel，100的redis-server master
查看101上的sentinel日誌，由於只有一個sentinel，只有101上的sentinel投票
恢復一個redis-sentinel，現有兩個redis-sentinel
查看sentinel日誌，選出101為master
有兩個sentinel或以上可以進行故障切換。單數sentinel更容易選出master，進行故障轉移。
+sdown：主觀down機
+odown：客觀down機
+new-epoch：集群遞增版本號
+vote-for-leader：在哨兵集群中投票選舉出一個哨兵，作為本次執行故障轉移操作的leader
+try-failover：開始對某ip進行故障轉移
voted for：另一個哨兵進行投票
+elected-leader：在哨兵集群中再次確認進行即將執行故障轉移的leader是哪一個哨兵。
+selected-slave slave：選出leader
+failover-state-send-slaveof-noone slaveLeader：向目標slave發送"slaveof-noone"指令，令其不要再做其它任何節點的slave了，從現在開始，它就是老大，完成從slave到master的轉換。
+failover-state-wait-promotion slave：等待其它的sentinel確認slave
+promoted-slave slave：其它的sentinel全部確認成功
+failover-state-reconf-slaves：開始對集群中的所有slave做reconf操作(更新配置信息)
+slave-reconf-sent：向指定的slave發送"slaveof"指令，令其跟隨新的master
+switch-master：故障轉移完畢後，各個sentinel開始監控新的master
㈦ redis哨兵模式從節點掛了應用報錯
換了返喊節點報錯說明漏察野應用節點不穩定與節點的兼容性較沒鏈差。需要重新更換節點進行操作嘗試重新連接，以便恢復正常使用，仍然不能使用，請重裝redis即可
㈧ redis哨兵故障轉移及實現
sentinel 是一個特殊的 redis 節點，它有自己專屬的 api ：
sentinel masters
展示所有被監控的主節點狀態及相關信息：
sentinel master <master name>
展示指定 <master name> 狀態以及相關的信猜梁息：
sentinel slaves <master name>
展示指定 <master name> 的從節點狀態以及相關的統計信息：
sentinel sentinels <master name>
展示指定 <master name> 的 sentinel 節點集合（不包含當前 sentinel 節點）：
sentinel get-master-addr-by-name <master name>
獲取主節點信息：
sentinel failover <master name>
對 <master name> 進行強制故障轉移：
修改配置：
Master 可能會因為某些情況宕機了，如果客戶端是固定一個地址去訪問，肯定是不合理的，所以客戶端請求是請求哨兵，從哨兵獲取主機地址的信息，或者是從機的信息。可以實現一個例子：
執行 docker-composer up 之後 sentinel.conf 發生了變化，每個配置文件變化如下：
sentinelconfsentinel.conf
sentine2confsentinel.conf
sentine3confsentinel.conf
從變化中可以看出每台 Sentinel 分別記錄了 slave 的節點信息和其它 Sentinel 節點信息。
在宿主機中隨便進入一台 Sentinel ：
可以觀察到監聽的所有 master ，將 192.168.3.2 這台 master 進行宕機
docker stop redis-master
宕機完之後等待 Sentinel 檢測周期過了之後再對 sentinel.conf 和 redis.conf 進行觀察。
3台氏銀 Sentinel 的 sentinel monitor mymaster 192.168.3.2 6379 2 變成了 sentinel monitor mymaster 192.168.3.4 6379 2
其次master對應的slave節點信息也進行更改。
而 192.168.3.3 的 redis.conf 中 replicaof 192.168.3.2 6379 也變成了 replicaof 192.168.3.4 6379 。
192.168.3.2 的 redis.conf 中 replicaof 192.168.3.2 6379 這行配置被刪除掉了。
再次啟動 192.168.3.2 的 redis 節點，而這台節點的 redis.conf 中增加了一行 replicaof 192.168.3.4 6379 。
其實就是將我們的操作自動化了。
Sentinel 的實現原理，穗核運主要分為三個步驟：
回顧上一篇文章中 Sentinel 的配置。
主觀下線：每個 Sentinel 節點對 Redis 失敗的「偏見」。之所以是偏見，只是因為某一台機器30s內沒有得到回復。
客觀下線：這個時候需要所以 Sentinel 節點都發現它30s內無回復，才會達到共識。
Redis 內部其實是有一個優先順序配置的，在配置文件中 replica-priority ，這個參數是 slave 節點的優先順序配置，如果存在則返回，如果不存在則繼續。當上面這個優先順序不滿足的時候， Redis 還會選擇復制偏移量最大的 Slave 節點，如果存在則返回，如果不存在則繼續。之所以選擇偏移量最大，這是因為偏移量越小，和 Master 的數據越不接近，現在 Master 掛掉了，說明這個偏移量小的機器數據可能存在問題，這就是為什麼選擇偏移量最大的 Slave 的原因。如果發現偏移量都一樣，這個時候 Redis 會默認選擇 runid 最小的節點。
生產環境部署技巧：
哨兵集群在發現 master node 掛掉後會進行故障轉移，也就是啟動其中一個 slave node 為 master node 。在這過程中，可能會導致數據丟失的情況。
造成的問題：
此時哨兵可能就會認為 master 宕機了，然後開始選舉，將其它 slave 切換成 master 。這時候集群里就會有2個 master ，也就是所謂的腦裂。此時雖然某個 slave 被切換成 master ，但是可能 client 還沒來得及切換成新的 master ，還繼續寫向舊的 master 的數據可能就丟失了。因此舊 master 再次被恢復的時候，會被作為一個 slave 掛到新的 master 上去，自己的數據會被清空，重新從新的 master 復制數據。
怎麼解決：
要求至少有一個 slave ，數據復制和同步的延遲不能超過10s。
如果說一旦所有的 slave ，數據復制和同步的延遲都超過了10s，這個時候， master 就不會再接收任何請求了。
上面兩個配置可以減少非同步復制和腦裂導致的數據丟失。
非同步復制導致的數據丟失：
在非同步復制的過程當中，通過 min-slaves-max-lag 這個配置，就可以確保的說，一旦 slave 復制數據和 ack 延遲時間太長，就認為可能 master 宕機後損失的數據太多了，那麼就拒絕寫請求，這樣就可以把 master 宕機時由於部分數據未同步到 slave 導致的數據丟失降低到可控范圍內。
集群腦裂導致的數據丟失：
集群腦裂因為 client 還沒來得及切換成新的 master ，還繼續寫向舊的master的數據可能就丟失了通過 min-slaves-to-write 確保必須是有多少個從節點連接，並且延遲時間小於 min-slaves-max-lag 多少秒。
客戶端需要怎麼做：
對於 client 來講，就需要做些處理，比如先將數據緩存到內存當中，然後過一段時間處理，或者連接失敗，接收到錯誤切換新的 master 處理。
㈨ 5.Redis的哨兵服務
0.Redis主從架構的問題
1.哨兵服務介紹
2.架構圖
3.主從服務搭建
4.配置哨兵服務
5.啟動哨兵服務吵肢
6.驗證哨兵服務
對於Redis的主從架構而言，無法實現 master 和 slave 角色的自動切換， 即當 master 出現 redis 服務異常、主機斷電、磁碟損壞等問題導致 master 無法使用，而 redis 高可用無法實現自故障轉移(將 slave 提升為 master)，需要手動改環境配置才能切換到 slave redis 伺服器。另外無法橫向擴展 Redis 服務的並行寫入性能， 當單台 Redis 服早派務器性能無法滿足業務寫入需求的時候就必須需要一種方式解決此問題。
1.master和slave角色的無縫切換，讓業務無感知從而不影響業務使用
2.可以橫向動態擴展Redis伺服器, 從而實現多台伺服器並行寫入以實現更高並發的目的。
Sentinel進程是用於監控redis集群中Master主伺服器工作的狀態，在Master主伺服器發生故障的時候，可以實現Master和Slave伺服器的切換，保證系統的高可用，其已經被集成在 redis2.6+的版本中，Redis的哨兵模式到了2.8版本之後就穩定了下來。一般在生產環境也建議使用Redis2.8以後版本。哨兵(Sentinel)是一個分布式系統，你可以在一個架構中運行多個哨兵(sentinel) 進程，這些進程使用流言協議(gossipprotocols)來接收關於Master主伺服器是否下線的信息，並使用投票協議(Agreement Protocols)來決定是否執行自動故障遷移,以及選擇哪個 Slave 作為新的 Master。每個哨兵(Sentinel)進程會向其它哨兵(Sentinel)、Master、Slave定時發陸碰賀送消息，以確認對方是否」活」著，如果發現對方在指定配置時間(可配置的)內未得到回應，則暫時認為對方已掉線，也就是所謂的」主觀認為宕機」 ，英文名稱：Subjective Down，簡稱SDOWN。有主觀宕機，肯定就有客觀宕機。當「哨兵群」中的多數 Sentinel 進程在對 Master 主伺服器做出 SDOWN 的判斷，並且通過SENTINEL is-master-down-by-addr 命令互相交流之後，得出的Master Server下線判斷，這種方式就是「客觀宕機」，英文名稱是： Objectively Down， 簡稱 ODOWN。通過一定的 vote 演算法，從剩下的 slave 從伺服器節點中，選一台提升為 Master 伺服器節點，然後自動修改相關配置，並開啟故障轉移（failover）。Sentinel 機制可以解決 master 和 slave 角色的切換問題。
安裝
修改配置文件
啟動服務
192.168.177.139
192.168.177.140
其他地方配置和主伺服器一致
啟動服務
查看主從狀態
MASTER
SLAVE1
SLAVE2
MASTER
SLAVE1
SLAVE2
主伺服器
SLAVE1：升級為主伺服器
SLAVE2：主伺服器變為node10
主伺服器
從伺服器
㈩ redis sentinel(哨兵)模式
本文使用docker啟動的sentinel，啟動腳本如下
發現最後的sentinels=3，說明有3個哨兵服務正在監控
報錯、此時sentinel可以獲取到主節點信息，但是獲取的ip為docker內部配置的地址
配置完畢