【NoSQL】拋棄VIP，使用consul和sentinel構建redis的高可用系統

背景：

1.傳統redis高可用方案只加了sentinel，在主庫故障后，雖然可以選主，然后切換只讀參數，但是，對應用來說卻需要更改連接的IP或者在hosts中更改解析。算得上是半自動。
2.利用consul系統的服務注冊與服務健康檢查功能可以實現全自動的故障切換與地址解析。

架構：

搭建：

1.建立consul集群,在redis節點上布置consul agent
2.建立sentinel集群
3.注冊服務（重點）

• 首先在redis2222實例上新建redis主從檢測腳本

  cat >/root/check/redis_role.sh<<EOF
  #!/bin/bash
  PORT=$1
  ROLE=$2
  a=$(redis-cli -p $PORT info Replication|grep role:|awk -F ':' '{print $2}'|awk -F '\r' '{print $1}' )
   if [ $a = $ROLE ]; then
   exit 0
  else
   exit 2
      fi
  EOF

  注：腳本使用方式：/root/check/redis_role.sh 2222 master
  第一個參數2222代表端口
  第二個參數master代表主，也可使用slave
  原理：摘出info命令中replication段的role屬性，然后和第二個變量相對比，相同，則輸出0
  （shell腳本正常運行的返回值），否則返回2（shell腳本執行異常的返回值）

• 其次：創建consul的redis服務配置文件

      cat >/etc/consu/redis_2222.json<<EOF
       {
          "services":[
              {
               "id":"2222master",
               "name":"redis-master",
               "tags":["master"],
               "address":"192.168.1.131",
               "port":2222,
               "check":[
                              {
                                  "args":["/root/check/redis_role.sh","2222","master"],
                                  "interval":"3s"
                               }
                             ]
              },
              {
               "id":"2222slave",
               "name":"2222slave"
               "tags":["slave"]
               "address":"192.168.1.131"
               "port":2222
               "checks":[
                               {
                                  "args":["/root/check/redis_role.sh","2222","slave"],
                                  "interval":"3s"
                                }
                              ]
              }
          ]
      }
      EOF

  在redis3333實例所在的主機上同樣操作。
  解釋：在2222實例上我們注冊兩個服務，一個為redis-master，一個為redis-slave。
  在3333實例上也注冊了同樣的兩個服務，在consul系統中，將json配置文件中name屬性相同的
  服務視為同一個服務。因為consul本身是具備健康檢查的功能，一個服務中如果兩個節點都OK
  服務域名解析是將會輪詢到兩個節點中，但健康檢查失敗后，域名解析時會自動踢出fail節點。

    情況1：redis2222為主實例，redis3333為從實例
          通過在腳本對redis的主從屬性進行檢查， "args":["/root/check/redis_role.sh","2222","master"],
    在腳本中，我們設置了讀取傳入的兩個參數并進行使用，在consul配置文件中，對傳入參數
    需要使用“,”分割，并且無論數字或者字符串都需要加上雙引號。
    2222的實例中role為master，3333的實例role為 slave。分別滿足了redis-master和redis-slave
    的健康檢查，consul在解析redis-master.service.consul和redis-slave.service.consul時分別指向
    了redis2222的主機和redis3333的地址。
    此時：   ping redis-master.service.consul 》192.168.1.131
                  ping redis-slave.service.consul 》192.168.1.104
                  APP可以通過redis-master.service.consul:2222對redis進行寫入，
                  通過redis-master.service.consul:3333對redis進行分散讀請求
    consul web頁面如圖

情況2：redis2222節點故障，sentinel自動提升redis3333節點為主節點，2222重新上線后，被
    sentinel集群配置為指向3333的從節點。
         此時： ping redis-master.service.consul 》192.168.1.104
               ping redis-slave.service.consul 》192.168.1.131
    APP可以通過redis-master.service.consul:3333對redis進行寫入，
    通過redis-master.service.consul:2222對redis進行分散讀請求
    consul web頁面如圖

后記：   
    1.本文中為了顯著區分兩個redis實例，對端口進行了區分，實際應用推薦使用相同端口（如2222）
        這樣每次訪問redis-master.service.consul:2222都能訪問到主實例
            每次訪問redis-master.service.consul:2222都能訪問到從實例
    2. consul定期執行健康檢測腳本并接收返回值0作為服務處于正常的標志，返回值1作為服務處于警告
      狀態，除此之外任何其他返回值都被認為服務處于故障狀態。實際使用時根據自身情況設置健康檢測腳本
      執行的頻率
    3.這種切換架構的便利性建立在數據庫端可以自洽的完成主從選舉與切換的特性上，同理，這種思路還
      可以用在consul+MongoDB副本集，consul+PXC集群上。
    4.官方文檔地址:`https://www.consul.io/docs/index.html`
      相關配置文件已放置在GitHub:`https://github.com/naughtyGitCat/HA_DB/tree/master/Consul`