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进程:

redis高可用方案总结_第1张图片

在这个系统中,如果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 #从不同步。高效但是数据不会被持久化。

你可能感兴趣的:(redis)