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正好轮训到了主节点上。