redis高可用方案总结

使用Redis-Sentinel

Redis-Sentinel是Redis官方推荐的高可用性（HA）解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身（包括它的很多客户端）都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。

它的主要功能有以下几点：

不时地监控redis是否按照预期良好地运行；如果发现某个redis节点运行出现状况，能够通知另外一个进程(例如它的客户端)；能够进行自动切换，当一个master节点不可用时，能够选举出master的多个slave（如果有超过一个slave的话）中的一个来作为新的master，其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。

 

参考官方文档：https://redis.io/topics/sentinel 的最基本部署方式：有三个主机（也可以少一个slave机器，官方文档反对这么做），每个主机分别运行一个redis进程和一个sentinel进程，对外用户使用时就使用master1进程:

在这个系统中，如果master1所在的主机网络不可用了，sentinel2和sentinel3启动了failover并把slave1选举为master。Sentinel集群的特性保证了sentinel2和sentinel3得到了关于master的最新配置。但是sentinel1依然持着的是旧的配置，因为它与外界隔离了。当网络恢复以后，sentinel1将会更新它的配置。

 

如果客户端所连接的master被网络隔离，客户端将依然可以向master1写数据，但是当网络恢复后，master1就会变成redis的一个slave，那么在网络隔离期间，客户端向master1写的数据将会丢失。因为redis采用的是异步复制，在这样的场景下，没有办法避免数据的丢失。可以通过以下配置来配置master和slave，使得数据不会丢失。

min-slaves-to-write 1

min-slaves-max-lag 10

通过上面的配置，当一个redis是master时，如果它不能向至少一个slave写数据（上面的min-slaves-to-write指定了slave的数量），它将会拒绝接受客户端的写请求。由于复制是异步的，master无法向slave写数据意味着slave要么断开连接了，要么不在指定时间内向master发送同步数据的请求了（上面的min-slaves-max-lag指定了这个时间）。

 

我的方案总结：这个方案有点是redis官方的，功能性、稳定性都可以。在我们的场景中主要是以查询数据为主，3台机器3个地址端口都可以查，在查数据的过程中可以分别查这三台机器，查到一台上面有就可以，三台机器上的数据是一致的。写数据的频次可能没那么高，写数据只能往master机器上面写（往salve机器上写不进去），如果出现master机器坏掉了，会自动出现新的master，问题就是ip地址会变，那么写数据时候ip地址也会变，每天要更新数据写的时候我觉得也可以用读的那种方法，三台依次都写一下。然后定期检查三台机器的状态就可以实现高可用，数据稳定了。

 

使用redis集群的方案要3主3从才能高可用，至少6台机器，对硬件要求高点，具体实现出来效果跟上面的差不多，只是存储容量可以更大。

 

写shell脚本监控redis进程，如果没有自动重启，这样方式只能解决的问题就是机器、网络没问题，仅仅是redis进程出问题的情况，有局限性，但是也可以同时把这部分配置到服务器上，有可能会派上用场，样例代码如下：

#设置环境变量

source /etc/profile

#source ~/.bash_profile

# 日志输出

redisMonitorLog=/tmp/redisMonitor.log

# redis进程

redis_status=`ps -ef | grep redis|grep "redis-server"|grep -v grep|awk '{print $2}'`

#设置时间

monitor_date=`date`

#判断wasce是否工作

if [[ $redis_status ]]; then

echo -e '##### redis is work, thx god !!! #####'>>$redisMonitorLog

else

echo -e "##### redis isn't work, restart now !!! #####">>$redisMonitorLog

/etc/init.d/redisd stop

/etc/init.d/redisd start

fi

 

关于持久化是写在redis配置文件里的，会将数据集的快照dump到dump.rdb文件中。也可以通过配置文件来修改Redis服务器dump快照的频率，在conf文件中，搜索save可以看到下面的配置信息：

save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。

save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。

save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

这是RDB持久化配置，关于AOF持久化配置，在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always #每次有数据修改发生时都会写入AOF文件。

appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。

appendfsync no #从不同步。高效但是数据不会被持久化。