之前对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配合起来数据还是互相同步的，一致性也尚可。
