Redis全方位講解--哨兵模式(Sentinel模式)

前言

  當按照上一篇《redis主從復制》部署好之后,我們會想,一旦redis的master出現了宕機,并且我們并沒有及時發現,這時候就可能會出現數據丟失或程序無法運行。此時,redis的哨兵模式就派上用場了,可以用它來做redis的高可用。

 

功能作用

  1. 監控(monitoring):Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。
  2. 提醒(Notifation):當被監控的某個 Redis 服務器出現問題時, Sentinel 可以通過 API 向管理員或者其他應用程序發送通知。
  3. 自動故障轉移(Automatic failover):當一個主服務器不能正常工作時, Sentinel 會開始一次自動故障遷移操作, 它會將失效主服務器的其中一個從服務器升級為新的主服務器, 并讓失效主服務器的其他從服務器改為復制新的主服務器; 當客戶端試圖連接失效的主服務器時, 集群也會向客戶端返回新主服務器的地址, 使得集群可以使用新主服務器代替失效服務器。

 

部署

  同樣,我們還是將每個哨兵部署在一個單獨的容器中。

  sentinel配置文件

  redis-sentinel1:https://github.com/Johnson19900110/johnsondock/blob/master/redis-sentinel/config/sentinel.conf

  redis-sentinel2:https://github.com/Johnson19900110/johnsondock/blob/master/redis-sentinel/config/sentinel-slave1.conf

  redis-sentinel3:https://github.com/Johnson19900110/johnsondock/blob/master/redis-sentinel/config/sentinel-slave2.conf

  這三個配置文件一模一樣,都是監聽master的。要不你把這個配置文件copy到容器中,要不你就創建三份,分別掛載到容器中,這里選擇了后面一種方法。

  這里介紹幾個基本的配置

    sentinel monitor mymaster redis 6379 2 監聽的master的容器別名為redis,端口是6379,最后面的2是當大于等于2個哨兵認為master主觀下線后(無論這個值為多少,至少得有一半以上的哨兵判定master主觀下線后,master才會被客觀下線),master才會被客觀下線,這是sentinel重新從slave中選舉一個來當master。

    sentinel auth-pass mymaster 123456 如果master配置了密碼,則此項必須配置,否則sentinel會將master標記問主觀下線(sdown)。

 

  docker-composer配置文件

### REDIS-SENTINEL ################################################
  # master
  redis-sentinel:
    image: johnson19900110/redis-sentinel:latest
    restart: always  #如果master未開啟數據持久化,此項應該刪除
    volumes:
      - ./redis-sentinel/config/sentinel.conf:/usr/local/etc/redis/redis-sentinel.conf
    networks:
      - backend
    depends_on:
      - redis

  # redis sentinel slave 1
  redis-sentinel-slave1:
    image: johnson19900110/redis-sentinel:latest
    restart: always
    volumes:
      - ./redis-sentinel/config/sentinel-slave1.conf:/usr/local/etc/redis/redis-sentinel.conf
    networks:
      - backend
    depends_on:
      - redis-slave1
      - redis-sentinel

  # redis sentinel slave 2
  redis-sentinel-slave2:
    image: johnson19900110/redis-sentinel:latest
    restart: always
    volumes:
      - ./redis-sentinel/config/sentinel-slave2.conf:/usr/local/etc/redis/redis-sentinel.conf
    networks:
      - backend
    depends_on:
      - redis-slave2
      - redis-sentinel-slave1

  

  啟動容器

docker-compose up -d redis-sentinel-slave2

執行以上命令后,就啟動了三個哨兵模式的容器

這是我們進入容器,查看是否redis-sentinel是否在工作。 

我們可看到,已經與master建立連接,通過status=ok可以知道,master正在正常工作,并且有2個從節點和3個哨兵節點。現在你再打開sentinel的配置文件,會發現發生了改變。

conf文件被重寫了,并且哨兵模式會自動檢測到master的兩個slave和另外兩個sentinel。

 

故障演示

  1、使master宕機,只需要關閉master的容器即可。 

如果此時再去三個哨兵節點里用info sentinel查看信息。

會發現這時候master節點的address信息變了,這就說明哨兵模式起作用了。但他這里還是顯示新的master有兩個slave。是因為原master節點宕機了,一旦它重啟,sentinel就會把它變成新的master節點的slave節點。我們可以去172.18.0.6這個容器中看下。

可以用以上docker命令查看容器的IP地址。進入容器后,還是在redis-cli下用info replication查看信息。 

我們可以看到這個slave變成了新的master,另外一個slave也變成了新master節點的slave。如果你查看redis節點的配置文件,會發現也被重寫了。 這是我們再重啟原master節點試試(注意:當他重啟成功后,就變成了slave節點,所以要打開持久化配置)。

當容器重啟成功后,我們再去新的master節點中使用info replication查看下。

正如我們所料,它成為了新的master的slave節點。如果你查看原master的配置文件,會發現多了 

最后,因為新的master節點是slave節點升級的,所以他的持久化配置還是存在的,如果你想要關掉它,只需要進入redis-cli,然后執行

至此,一次redis的master節點故障轉移就演示完成了。這次演示實現了redis的監控自動故障轉移特性。

提醒特性是使用的訂閱功能,需要后端代碼開發配合的。

 

發布與訂閱信息

客戶端可以將 Sentinel 看作是一個只提供了訂閱功能的 Redis 服務器: 你不可以使用 PUBLISH 命令向這個服務器發送信息, 但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令, 通過訂閱給定的頻道來獲取相應的事件提醒。

一個頻道能夠接收和這個頻道的名字相同的事件。 比如說, 名為 +sdown 的頻道就可以接收所有實例進入主觀下線(SDOWN)狀態的事件。

通過執行 PSUBSCRIBE * 命令可以接收所有事件信息。

以下列出的是客戶端可以通過訂閱來獲得的頻道和信息的格式: 第一個英文單詞是頻道/事件的名字, 其余的是數據的格式。

注意, 當格式中包含 instance details 字樣時, 表示頻道所返回的信息中包含了以下用于識別目標實例的內容:

 

@ 字符之后的內容用于指定主服務器, 這些內容是可選的, 它們僅在 @ 字符之前的內容指定的實例不是主服務器時使用。

  • +reset-master :主服務器已被重置。
  • +slave :一個新的從服務器已經被 Sentinel 識別并關聯。
  • +failover-state-reconf-slaves :故障轉移狀態切換到了 reconf-slaves 狀態。
  • +failover-detected :另一個 Sentinel 開始了一次故障轉移操作,或者一個從服務器轉換成了主服務器。
  • +slave-reconf-sent :領頭(leader)的 Sentinel 向實例發送了 [SLAVEOF](/commands/slaveof.html) 命令,為實例設置新的主服務器。
  • +slave-reconf-inprog :實例正在將自己設置為指定主服務器的從服務器,但相應的同步過程仍未完成。
  • +slave-reconf-done :從服務器已經成功完成對新主服務器的同步。
  • -dup-sentinel :對給定主服務器進行監視的一個或多個 Sentinel 已經因為重復出現而被移除 —— 當 Sentinel 實例重啟的時候,就會出現這種情況。
  • +sentinel :一個監視給定主服務器的新 Sentinel 已經被識別并添加。
  • +sdown :給定的實例現在處于主觀下線狀態。
  • -sdown :給定的實例已經不再處于主觀下線狀態。
  • +odown :給定的實例現在處于客觀下線狀態。
  • -odown :給定的實例已經不再處于客觀下線狀態。
  • +new-epoch :當前的紀元(epoch)已經被更新。
  • +try-failover :一個新的故障遷移操作正在執行中,等待被大多數 Sentinel 選中(waiting to be elected by the majority)。
  • +elected-leader :贏得指定紀元的選舉,可以進行故障遷移操作了。
  • +failover-state-select-slave :故障轉移操作現在處于 select-slave 狀態 —— Sentinel 正在尋找可以升級為主服務器的從服務器。
  • no-good-slave :Sentinel 操作未能找到適合進行升級的從服務器。Sentinel 會在一段時間之后再次嘗試尋找合適的從服務器來進行升級,又或者直接放棄執行故障轉移操作。
  • selected-slave :Sentinel 順利找到適合進行升級的從服務器。
  • failover-state-send-slaveof-noone :Sentinel 正在將指定的從服務器升級為主服務器,等待升級功能完成。
  • failover-end-for-timeout :故障轉移因為超時而中止,不過最終所有從服務器都會開始復制新的主服務器(slaves will eventually be configured to replicate with the new master anyway)。
  • failover-end :故障轉移操作順利完成。所有從服務器都開始復制新的主服務器了。
  • +switch-master :配置變更,主服務器的 IP 和地址已經改變。 這是絕大多數外部用戶都關心的信息。
  • +tilt :進入 tilt 模式。
  • -tilt :退出 tilt 模式。
posted @ 2018-11-03 08:14 JohnsonChung 閱讀(...) 評論(...) 編輯 收藏
耐克篮球多少钱