之前对Redis的使用还是中规中矩的Master＋Slave，没有做到故障的自动切换，根据hey linux提供的redis HA方案，使用keepalived＋redis很容易搭建起来了高可用的redis集群，具体的搭建过程可以参考原始连接，本主重点是对高可用redis的验证。

测试节点：
Master: 172.16.31.101
Slave: 172.16.31.102
VIP: 172.16.31.100

究竟Keepalived＋redis的配置是否真的可靠，是Master＋slave还是Master＋Master呢？
下面开始测试：
Master＋slave配置下，客户端通过VIP连接redis，当Master 停掉以后，VIP切换到Slave上，但是测试中发现仍然可以向VIP（Slave）写数据（这点有些令人疑惑，因为配置里面是“slave-read-only yes”），这跟实际想像的不太一样，另外就是即使可以写了，那么能够同步回Master呢？

切换过程中抓取了replication的几个状态（取redis INFO数据）：

（一）正常状态，此时redis可写，set/get数据正常：

# Replication
role:master
connected_slaves:1
slave0:172.16.31.102,6379,online

$ redis-cli -h 172.16.31.100 -p 6379 SET foo bar
OK

（二）Master down（停掉Master）之后的状态，原来的Salve变成了Master，状态显示已经没有了Slave。

# Replication
role:master
connected_slaves:0

$ redis-cli -h 172.16.31.100 -p 6379 SET sitename sudops.com
OK

（三）Master恢复（重新启动）后：
状态发生了两次变化：
（a）从Slave同步数据到原来的Master上，能够看到原master的状态为up， 以及落后Slave的时间为4s（此时Slave不能写）

redis-cli -h 172.16.31.100 -p 6379 SET sitename sudops.com
(error) READONLY You can't write against a read only slave.

# Replication
role:slave
master_host:172.16.31.102
master_port:6379
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_priority:100
slave_read_only:1
connected_slaves:0

（b）同步之后恢复到正常状态，有一个Slave, get之前set的数据没有问题。

# Replication
role:master
connected_slaves:1
slave0:172.16.31.102,6379,online

$ redis-cli -h 172.16.31.100 -p 6379 GET sitename
"sudops.com"

看来即便是Master＋Slave的redis配置下与Keepalived配合起来数据还是互相同步的，一致性也尚可。

本文固定链接: https://sudops.com/keepalived-redis-hight-available-test.html | 运维速度