[[356563]]

本文轉載自微信公眾號「SH的全棧筆記」，作者SH 。轉載本文請聯系SH的全棧筆記公眾號。 

本篇博客會簡單的介紹Redis的Sentinel相關的原理，同時也會在最后的文章給出「硬核的」實戰教程，讓你在了解原理之后，能夠實際上手的體驗整個過程。

之前的文章聊到了Redis的主從復制，聊到了其相關的原理和缺點，具體的建議可以看看我之前寫的文章Redis的主從復制。

總的來說，為了滿足Redis在真正復雜的生產環境的高可用，僅僅是用主從復制是明顯不夠的。例如，當master節點宕機了之后，進行主從切換的時候，我們需要人工的去做failover。

同時在流量方面，主從架構只能通過增加slave節點來擴展讀請求，「寫能力」由于受到master單節點的資源限制是無法進行擴展的。

這也是為什么我們需要引入Sentinel。

Sentinel

功能概覽

Sentinel其大致的功能如下圖。

Sentinel

 

Sentinel是Redis高可用的解決方案之一，本身也是分布式的架構，包含了「多個」Sentinel節點和「多個」Redis節點。而每個Sentinel節點會對Redis節點和其余的Sentinel節點進行監控。

當其發現某個節點不可達時，如果是master節點就會與其余的Sentinel節點協商。當大多數的Sentinel節點都認為master不可達時，就會選出一個Sentinel節點對master執行故障轉移，并通知Redis的調用方相關的變更。

相對于「主從」下的手動故障轉移，Sentinel的故障轉移是全自動的，「無需」人工介入。

Sentinel自身高可用

666，那我怎么知道滿足它自身的高可用需要部署多少個Sentinel節點?

因為Sentinel本身也是分布式的，所以也需要部署多實例來保證自身集群的高可用，但是這個數量是有個最低的要求，最低需要「3個」。

我去，你說3個就3個?我今天偏偏就只部署2個

你別杠...等我說了為什么就必須要3個...

因為哨兵執行故障轉移需要「大部分」的哨兵都同意才行，如果只有兩個哨兵實例，正常運作還好，就像這樣。

 

如果哨兵所在的那臺機器由于機房斷電啊，光纖被挖啊等極端情況整個掛掉了，那么另一臺哨兵即使發現了master故障之后想要執行故障轉移，但是它無法得到任何「其余哨兵節點」的同意，此時也「永遠」無法執行故障轉移，那Sentinel豈不是成了一個擺設?

所以我們需要至少3個節點，來保證Sentinel集群自身的高可用。當然，這三個Sentinel節點肯定都推薦部署到「不同的」機器上，如果所有的Sentinel節點都部署到了同一臺機器上，那當這臺機器掛了，整個Sentinel也就不復存在了。

redis-sentinel-success

 

quorum&majority

大部分?大哥這可是要上生產環境，大部分這個數量未免也太敷衍了，咱就不能專業一點?

前面提到的大部分哨兵同意涉及到兩個參數，一個叫quorum，如果Sentinel集群有quorum個哨兵認為master宕機了，就「客觀」的認為master宕機了。另一個叫majority...

等等等等，不是已經有了一個叫什么quorum的嗎?為什么還需要這個majority?

你能不能等我把話說完...

quorum剛剛講過了，其作用是判斷master是否處于宕機的狀態，僅僅是一個「判斷」作用。而我們在實際的生產中，不是說只「判斷」master宕機就完了， 我們不還得執行「故障轉移」，讓集群正常工作嗎?

同理，當哨兵集群開始進行故障轉移時，如果有majority個哨兵同意進行故障轉移，才能夠最終選出一個哨兵節點，執行故障轉移操作。

主觀宕機&客觀宕機

你剛剛是不是提到了「客觀宕機」?笑死，難不成還有主觀宕機這一說?

 

Sentinel中認為一個節點掛了有兩種類型：

• Subjective Down，簡稱「sdown」，主觀的認為master宕機
• Objective Down，簡稱「odown」，客觀的認為master宕機

當一個Sentinel節點與其監控的Redis節點A進行通信時，發現連接不上，此時這個哨兵節點就會「主觀」的認為這個Redis數據A節點sdown了。為什么是「主觀」?我們得先知道什么叫主觀

未經分析推算，下結論、決策和行為反應，暫時不能與其他不同看法的對象仔細商討，稱為主觀。

❞簡單來說，因為有可能「只是」當前的Sentinel節點和這個A節點的網絡通信有問題，其余的Sentinel節點仍然可以和A正常的通信。

sentinel-sdown

 

這也是為什么我們需要引入「odown」，當大于等于了「quorum」個Sentinel節點認為某個節點宕機了，我們就「客觀」的認為這個節點宕機了。

當Sentinel集群客觀的認為master宕機，就會從所有的Sentinel節點中，選出一個Sentinel節點，來最終執行master的故障轉移。

那這個「故障轉移」具體要執行些什么操作呢?我們通過一個圖來看一下。

 

通知調用的客戶端master發生了變化

通知其余的原slave節點，去復制Sentinel選舉出來的新的master節點

如果此時原來的master又重新恢復了，Sentinel也會讓其去復制新的master節點。成為一個新的slave節點。

硬核教程

硬核教程旨在用最快速的方法，讓你在本地體驗Redis主從架構和Sentinel集群的搭建，并體驗整個故障轉移的過程。

前置要求

1. 安裝了docker
2. 安裝了docker-compose

準備compose文件

首先需要準備一個目錄，然后分別建立兩個子目錄。如下。

$ tree . 
. 
├── redis 
│   └── docker-compose.yml 
└── sentinel 
    ├── docker-compose.yml 
    ├── sentinel1.conf 
    ├── sentinel2.conf 
    └── sentinel3.conf 
 
2 directories, 5 files 

搭建Redis主從服務器

redis目錄下的docker-compose.yml內容如下。

version: '3' 
services: 
  master: 
    image: redis 
    container_name: redis-master 
    ports: 
      - 6380:6379 
  slave1: 
    image: redis 
    container_name: redis-slave-1 
    ports: 
      - 6381:6379 
    command:  redis-server --slaveof redis-master 6379 
  slave2: 
    image: redis 
    container_name: redis-slave-2 
    ports: 
      - 6382:6379 
    command: redis-server --slaveof redis-master 6379 

以上的命令，簡單解釋一下slaveof

就是讓兩個slave節點去復制container_name為redis-master的節點，這樣就組成了一個簡單的3個節點的主從架構

然后用命令行進入當前目錄，直接敲命令docker-compose up即可，剩下的事情交給docker-compose去做就好，它會把我們所需要的節點全部啟動起來。

此時我們還需要拿到剛剛我們啟動的master節點的IP，簡要步驟如下：

1.通過docker ps找到對應的master節點的containerID

$ docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES9f682c199e9b redis "docker-entrypoint.s…" 3 seconds ago Up 2 seconds 0.0.0.0:6381->6379/tcp redis-slave-12572ab587558 redis "docker-entrypoint.s…" 3 seconds ago Up 2 seconds 0.0.0.0:6382->6379/tcp redis-slave-2f70a9d9809bc redis "docker-entrypoint.s…" 3 seconds ago Up 2 seconds 0.0.0.0:6380->6379/tcp redis-master 

也就是f70a9d9809bc。

2.通過docker inspect f70a9d9809bc，拿到對應容器的IP，在NetworkSettings -> Networks -> IPAddress字段。

然后把這個值給記錄下來，此處我的值為172.28.0.3。

搭建Sentinel集群

sentinel目錄下的docker-compose.yml內容如下。

version: '3' 
services: 
  sentinel1: 
    image: redis 
    container_name: redis-sentinel-1 
    ports: 
      - 26379:26379 
    command: redis-sentinel /usr/local/etc/redis/sentinel.conf 
    volumes: 
      - ./sentinel1.conf:/usr/local/etc/redis/sentinel.conf 
  sentinel2: 
    image: redis 
    container_name: redis-sentinel-2 
    ports: 
    - 26380:26379 
    command: redis-sentinel /usr/local/etc/redis/sentinel.conf 
    volumes: 
      - ./sentinel2.conf:/usr/local/etc/redis/sentinel.conf 
  sentinel3: 
    image: redis 
    container_name: redis-sentinel-3 
    ports: 
      - 26381:26379 
    command: redis-sentinel /usr/local/etc/redis/sentinel.conf 
    volumes: 
      - ./sentinel3.conf:/usr/local/etc/redis/sentinel.conf 
networks: 
  default: 
    external: 
      name: redis_default 

同樣在這里解釋一下命令

redis-sentinel 命令讓 redis 以 sentinel 的模式啟動，本質上就是一個運行在特殊模式的 redis 服務器。

和 redis-server 的區別在于，他們分別載入了不同的命令表，sentinel 中無法執行各種redis中特有的 set get操作。

建立三份一模一樣的文件，分別命名為sentinel1.conf、sentinel2.conf和sentinel3.conf。其內容如下：

port 26379 
dir "/tmp" 
sentinel deny-scripts-reconfig yes 
sentinel monitor mymaster 172.28.0.3 6379 2 
sentinel config-epoch mymaster 1 
sentinel leader-epoch mymaster 1 

可以看到，我們對于sentinel的配置文件中，sentinel monitor mymaster 172.28.0.3 6379 2表示讓它去監聽名為mymaster的master節點，注意此處的IP一定要是你自己master節點的IP，然后最后面的2就是我們之前提到的quorum。

然后命令行進入名為sentinel的目錄下，敲docker-compose up即可。至此，Sentinel集群便啟動了起來。

手動模擬master掛掉

然后我們需要手動模擬master掛掉，來驗證我們搭建的Sentinel集群是否可以正常的執行故障轉移。

命令行進入名為redis的目錄下，敲入如下命令。

docker-compose pause master 

此時就會將master容器給暫停運行，讓我們等待「10秒」之后，就可以看到sentinel這邊輸出了如下的日志。

redis-sentinel-2 | 1:X 07 Dec 2020 01:58:05.459 # +sdown master mymaster 172.28.0.3 6379 
...... 
...... 
...... 
redis-sentinel-1 | 1:X 07 Dec 2020 01:58:06.932 # +switch-master mymaster 172.28.0.3 6379 172.28.0.2 6379 

得得得，你干什么就甩一堆日志文件上來?湊字數?你這樣鬼能看懂?

❞的確，光從日志文件一行一行的看，就算是我自己過兩周再來看，也是一臉懵逼。日志文件完整了描述了整個Sentinel集群從開始執行故障轉移到最終執行完成的所有細節，但是在這里直接放出來不方便大家的理解。

所以為了讓大家能夠更加直觀的了解這個過程，我簡單的把過程抽象了成了一張圖，大家看圖結合日志，應該能夠更容易理解。

 

sentinel-process

 

里面關鍵的步驟步驟的相關解釋我也一并放入了圖片中。

最終的結果就是，master已經從我們最開始的172.28.0.3切換到了172.28.0.2，后者則是原來的slave節點之一。此時我們也可以連接到172.28.0.2這個容器里去，通過命令來看一下其現在的情況。

role:masterconnected_slaves:1slave0:ip=172.28.0.4,port=6379,state=online,offset=18952,lag=0master_replid:f0bf5d1c843ec3ab005c5ac2b864f7ffdc6a8217master_replid2:72c43e1f9c05d4b08bea6bf9b2549997587e261cmaster_repl_offset:18952second_repl_offset:16351repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:1repl_backlog_histlen:18952

可以看到，現在的172.28.0.2這個節點的角色已經變成了「master」，與其相連接的slave節點只有1個，因為現在的「原master」還沒有啟動起來，總共存活的只有2個實例。

原master重啟啟動

接下來我們模擬原master重新啟動，來看一下會發什么什么。

還是通過命令行進入到名為redis的本地目錄，通過docker-compose unpause master來模擬原master故障恢復之后的上線。同樣我們連接到原master的機器上去。

$ docker exec -it f70a9d9809bc1e924a5be0135888067ad3eb16552f9eaf82495e4c956b456cd9 /bin/sh; exit 
# redis-cli 
127.0.0.1:6379> info replication 
# Replication 
role:slave 
master_host:172.28.0.2 
master_port:6379 
master_link_status:up 
...... 

master斷線重連之后，角色也變成了新的master(也就是172.28.0.2這個節點)的一個slave。

然后我們也可以通過再看一下新master節點的replication情況作證。

# Replication 
role:master 
connected_slaves:2 
slave0:ip=172.28.0.4,port=6379,state=online,offset=179800,lag=0 
slave1:ip=172.28.0.3,port=6379,state=online,offset=179800,lag=1 
...... 

 

原master短線重連之后，其「connected_slaves」變成了2，且「原master」172.28.0.3被清晰的標注為了slave1，同樣與我們開篇和圖中所講的原理相符合。