Redis5.0+哨兵模式+Keepalived實現高可用

Redis主備配置

原理：

從服務器向主服務器發出SYNC指令，當主服務器接到此命令後，就會調用BGSAVE指令來建立一個子進程專門進行數據持久化工做，也就是將主服務器的數據寫入RDB文件中。在數據持久化期間，主服務器將執行的寫指令都緩存到內存中。

在BGSVAE指令執行完成後，主服務器會將持久化好的RDB文件發送給從服務器，從服務器接到此文件後會將其存儲到磁盤上，而後再將其讀取到內存中。這個動做完成以後，主服務器會將這段時間緩存的寫指令再以redis協議的格式發給從服務器。

1.redis安裝

$ tar xf redis-5.0.3.tar.gz 
$ mv redis-5.0.3 redis
$ yum -y install gcc gcc-c++ jemalloc-devel
$ cd redis
$ make

　　

2.配置主從

$ cp redis.conf redis_7000.conf
$ vim redis_7000.conf
    port 7000
    pidfile /var/run/redis_7000.pid
    logfile /var/log/7000.log
    dir ./7000
​
    # replicaof <masterip> <masterport>：主服務這句話註釋，從服務配置的須要開啓。配置主服務的ip的port。 
​
    # 主端的密碼
    masterauth  
    # 客戶端訪問密碼
    requirepass

3.配置哨兵模式

$ vim sentinel.conf 
    daemonize yes
    logfile /var/log/redis-sentinel.log
    # 多少毫秒沒有接收到主節點的反饋，認爲主節點down
    sentinel down-after-milliseconds mymaster 60000
    # 哨兵監控主節點的IP和端口   1表示至少一個節點認爲主節點down了，纔開始選舉新節點
    sentinel monitor mymaster 127.0.0.1 7000 1
    # failover過時時間
    sentinel failover-timeout mymaster 30000
    # 配置哨兵鏈接主節點的認證密碼。（主節點配置的requirepass）
    sentinel auth-pass mymaster ypmdd21312@#asdhjs@#!

　　

若是Master宕機切換到Slave上，直接向slave寫數據，以後將slave的角色切換成Master，原來的master從新加入到主從中，成爲slave，對數據不會有影響。

 

Redis啓動的一些警告

# WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

　　

警告：過量使用內存設置爲0！在低內存環境下，後臺保存可能失敗。

$ vim /etc/sysctl.conf
    vm.overcommit_memory = 1
$ sysctl -p

　　

4.檢測

查看master或者slave狀態

$ redis-cli -a 密碼 （沒有密碼則忽略-a）
$ INFO REPLICATION

查看哨兵狀態

cat /var/log/redis-sentinel.log

keepalived

1.安裝keepalived服務

$ yum -y install keepalived

2.配置keepalived

$ vim /etc/keepalived/keepalived.conf 
global_defs {
   router_id redis1
}
​
vrrp_instance VI_1 {
    state BACKUP
    nopreempt
    interface eth0
    virtual_router_id 51
    priority 100
    # 本機ip地址
    unicast_src_ip 10.13.2.230
    # 對端ip地址，必須寫成三行的形式
    unicast_peer {
        10.13.14.196
    }
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        10.13.171.98                #HAVIP
    }
}
​
virtual_server 10.13.171.98 6379 {
    delay_loop 3
    lb_algo rr
    lb_kind DR
    persistence_timeout 50
    protocol TCP
​
    real_server 10.13.2.230 6379 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
        }
    }
    real_server 10.13.14.196 6379 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
        }
    }
}

3.啓動服務

$ systemctl start keepalived

4.測試

$ ip a

5.配置腳本

$ vim /etc/keepalived/keepalived.conf
···
    vrrp_script check_redis {
        script "/etc/keepalived/check_redis.sh"
        interval 3
    }
···
    vrrp_instance VI_1 {
        track_script {
            check_redis
        }
    }
$ vim /etc/keepalived/check_redis.sh
    #/bin/bash
    port=`ss -antp | grep 7000 | grep LISTEN | wc -l `
    if [ $port -eq 0 ];then
            systemctl stop keepalived
    fi

雲上佈置Keepalived的問題

# 本機ip地址 
unicast_src_ip 10.13.2.230
# 對端ip地址，必須寫成三行的形式
unicast_peer {
    10.13.14.196
}

路由交換層禁用了ARP的廣播限制，形成keepalived主備沒法通z過vrrp協議廣播的方式進行通信，形成了兩端都會產生HAVIP。必須配置指定IP的兩臺服務器間進行通信。

telnet+端口不成功

ping端口沒有問題，可是telnet VIP + 服務端口會偶爾出現問題，telnet VIP +其餘端口 沒有問題。

virtual_server 10.13.171.98 6379 {
    delay_loop 3
    #lb_algo rr
    #lb_kind DR
    persistence_timeout 50
    protocol TCP

　　

由於用不到LVS的調度算法lb_algo和轉發方式lb_kind,這兩個會影響到telnet VIP+配置的端口。

緣由：

由於若是採用了lvs的轉發方式的話，以DR模式爲例，直接將請求轉發給了後端的真實服務器，可是目的ip爲vip，後端的服務器上沒有vip，因此致使請求沒法響應。偶爾能夠成功是由於rr正好輪訓到了主節點上。