Redis实践(二)高可用的集群+哨兵部署

 项目中通常会需要若干台Redis服务器来协同担当起内存数据库的工作,在redis的部署方案上要考虑下面几点:

结构上,单个 Redis 服务器会发生单点故障,而且一台服务器需要承受所有的请求负载。 这就需要为数据生成多个副本并分配在不同的服务器上; 

容量上,单个 Redis 服务器的内存非常容易成为存储瓶颈,所以需要进行数据分片。

同时拥有多个 Redis 服务器后就会面临如何管理集群的问题,包括如何增加节点、故障恢复等操作。

本次实践的目标就是从高可用的角度,针对redis的集群和哨兵方案的部署实践。

一、目标

使用高可用的redis集群和哨兵方案,进行部署。

        模拟当主redis宕机的情况下,redis服务能够正常使用。

        当宕机故障恢复后,数据和服务可以正常使用。

二、部署环境和方案

       主Redis : centos6.5 192.168.136.144  后面用144主机来说明

       从Redis: centos6.5  192.168.136.155  后面用155主机来说明

       哨兵:  哨兵在144主机上部署2个,在155主机上部署1个。

       采用 redis版本为 redis-3.2.3.tar.gz

       2.1 整体部署图如下:

      Redis实践(二)高可用的集群+哨兵部署_第1张图片

         2.2 方案描述:

Redis缓存服务采用Master-Slaver模式,Master节点负责读写操作,Slaver节点负责从Master节点上做Replication的复制。Master和Slaver节点分别部署在不同主机上,组成一组Redis服务。Redis组内采用Redis官方提供的Sentinel(哨兵)机制做failover,通过sentinel模式启动redis后,自动监控master/slave的运行状态,基本原理是:心跳机制+投票裁决。
在Redis现在的版本中,都融合了Sentine服务,基于Sentinel的主从切换方案,Sentinel用于管理多个Redis服务器实例,主要负责三个方面的任务:
  1. 监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。每个sentinel会向其它sentinal、master、slave定时发送消息,以确认对方是否“活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的“主观认为宕机” Subjective Down,简称SDOWN)。若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称ODOWN)。
2. 提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
  3. 自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会通过一定的vote算法,从失效主服务器的其中一个从服务器升级为新的主服务器, 并自动修改相关配置,让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。当失效的Master恢复后,Redis Sentinel会自动识别,将Master自动转换为Slave并完成数据同步。通过Redis Sentinel可以实现Redis零手工干预并且短时间内进行M-S切换,减少业务影响时间。

2.3 缓存主要设置
持久化策略:Master采用快照方式生成RDB文件,Slave采用快照方式生成RDB文件的同时利用增加AOF策略。
虚拟内存:关闭
最大内存:60%~80%物理内存
2.4 队列主要设置
持久化策略:关闭
虚拟内存:关闭
最大内存:60%~80%物理内存

三、部署步骤

3.1 主Redis安装和配置

   3.1.1 主Redis的安装
   Redis的安装,可以参考博文实践(一)的内容进行。部署完成后,我们需要进行集群的配置

   3.1.2 主Redis的配置
   进入/usr/local/etc/redis 目录,我们可以查看到有下列文件
   [root@cwqsolo redis]# ls  -ltr
total 52
-rw-r--r-- 1 root root 46696 Nov  9 19:10 redis.conf
-rw-r--r-- 1 root root    95 Nov 12 04:14 dump.rdb
[root@cwqsolo redis]# 
    现在,我们要修改配置文件,使之可以支持集群
    在这个目录下,创建一个Master使用的配置目录 
    mkdir  6379
    cp ./redis.conf  ./6379/redis6379.conf
    
    然后,我们要修改redis6379.conf的内容:
daemonize yes
pidfile /var/run/redis6379.pid
port 6379
#根据所在主机ip更改
bind 192.168.136.144
logfile /home/lteapp/redis/6379/redis.log
dbfilename dump.rdb
#dir是dump.rdb文件存放的路径,存放redis内存数据的快照
dir /home/lteapp/redis/6379/
repl-ping-slave-period 10
repl-timeout 120
client-output-buffer-limit slave 512mb 128mb 120
Redis实践(二)高可用的集群+哨兵部署_第2张图片

Redis在主从复制时,需要fork子进程来进行操作,如果你的应用堆积了很大数据在内存中,那么就需要针对这个子进程申请相应的内存空间,此时会受到操作系统的限制。通过更改系统配置文件/etc/sysctl.conf的vm.overcommit_memory=1以永久生效。
vi /etc/sysctl.conf
修改
vm.overcommit_memory=1

   3.1.3 验证一下redis master 已经成功安装
  启动方式: redis-server  /usr/local/etc/redis/6379/redis6379.conf
  注意启动后,可以通过redis-cli进行控制和交互。
  停止方式:redis-cli -h 192.168.136.144 -p 6379

  进入后,输入shutdown
  注意这里需要添加-h参数,如果不添加此参数,会报告如下异常:
  Could not connect to Redis at 127.0.0.1:6379: Connection refused
  原因就是在conf文件中,我们配置 bind 参数
  info  命令可以查看redis的完整信息。
  至此,redis单节点安装完毕。 
  
  为了适应集群的安装
 1) 首先修改redis conf配置,使之适应
  pidfile /var/run/redis-M-6379.pid
##日志刷新策略(Master禁用)
#save 900 1
#save 300 10
#save 60 10000
#镜像备份文件的文件名
dbfilename redis-35-M_dump.rdb
##启用增量(Master禁用) 
appendonly no 
##slaveof no one  
slave-read-only yes  
 
3.1.2 Redis slave 安装和配置
  首先和上面安装Redis Master 一样,进行安装,以及各个目录建立,可以拷贝144上Mater的配置文件。
  我们这里假设已经拷贝完成,那么我们需要修改下面信息以满足slave的设置需要。
port 6379  
##Redis 默认pid 文件位置redis.pid,当运行多个 redis 服务时,需要指定不同的 pid 文件和端口
pidfile redis-S-6379.pid
##日志刷新策略(Master禁用)
save 900 1
save 300 10
save 60 10000
#镜像备份文件的文件名
dbfilename redis-S-dump.rdb


##启用增量(Master禁用) 
appendonly yes
##设置该数据库为其他数据库的从数据库,主库无需设置
slaveof 192.168.136.144 6379
##-----------其他配置和master保持一致-----------##
  
3.1.3 Redis Sentinel 安装配置
先在redis根目录下创建conf子目录,把默认的sentinel.conf文件复制进来,重命名为sentinel-16379.conf,并修改以下配置信息:
进入 /home/nmc/dev/redis/redis-3.2.3,然后执行cp  sentinel.conf    /usr/local/etc/redis/6379命令
接下来,我们进入 /usr/local/etc/redis/6379  目录将哨兵配置文件改名,mv sentinel.conf  sentinel-1-16379.conf
修改内容如下:
##sentinel-16379.conf 
##sentinel实例之间的通讯端口  
port 16379  
##指定工作目录
dir /home/nmc/dev/redis/redis6379/sentinel-1
##显示监控master节点10.45.47.35,master节点使用端口6379,最后一个数字表示投票需要的"最少法定人数",比如有10个sentinal哨兵都在监控某一个master节点,如果需要至少6个哨兵发现master挂掉后,才认为master真正down掉,那么这里就配置为6,最小配置1台master,1台slave,在二个机器上都启动sentinal的情况下,哨兵数只有2个,如果一台机器物理挂掉,只剩一个sentinal能发现该问题,所以这里配置成1,至于mymaster只是一个名字,可以随便起,但要保证下面使用同一个名字
sentinel monitor mymaster 192.168.136.144 6379 1  
##表示如果10s内mymaster没响应,就认为SDOWN
sentinel down-after-milliseconds mymaster 10000  
##表示如果master重新选出来后,其它slave节点能同时并行从新master同步缓存的台数有多少个,显然该值越大,所有slave节点完成同步切换的整体速度越快,但如果此时正好有人在访问这些slave,可能造成读取失败,影响面会更广。最保定的设置为1,只同一时间,只能有一台干这件事,这样其它slave还能继续服务,但是所有slave全部完成缓存更新同步的进程将变慢。
sentinel parallel-syncs mymaster 1  
##表示如果15秒后,mysater仍没活过来,则启动failover,从剩下的slave中选一个升级为master
sentinel failover-timeout mymaster 15000    
##当failover时,指定一个“通知”脚本用来告知系统管理员,当前集群的情况。脚本被允许执行的最大时间为60秒,如果超时,脚本将会被终止(KILL)  脚本执行的结果:  1:稍后重试,最大重试次数为10; 2: 执行结束,无需重试

部署完Sentinel-1 后,我们在144主机上部署Sentinel-2
cp  /usr/local/etc/redis/6379/sentinel-1-16379.conf  sentinel-2-26379.conf
修改sentinel-2-26379.conf  中如下内容
port  26379
dir /home/nmc/dev/redis/redis6379/sentinel-2

接着,我们在155主机上部署Sentinel-3
进入/usr/local/etc/redis/6379/目录,执行如下命令
scp   [email protected]:/usr/local/etc/redis/6379/sentinel-1-16379.conf  .
将远程144机器上的文件拷贝到本地
mv sentinel-1-16379.conf sentinel-3-16379.conf
无需修改内容
在155主机上,要建立conf文件中的目录
mkdir /home/nmc/dev/redis/redis6379/sentinel-2


3.1.4 启动验证:
144、155主机上执行下面的启动命令:
redis-server  /usr/local/etc/redis/6379/redis6379.conf 

启动sentinel
144机器上,启动2个哨兵
nohup redis-sentinel  /usr/local/etc/redis/6379/sentinel-1-16379.conf > /home/nmc/dev/redis/redis6379/sentinel-1/redis-sentinel-1.log 2>&1 &  
nohup redis-sentinel  /usr/local/etc/redis/6379/sentinel-2-26379.conf > /home/nmc/dev/redis/redis6379/sentinel-2/redis-sentinel-2.log 2>&1 &  

155上启动1个哨兵
nohup redis-sentinel  /usr/local/etc/redis/6379/sentinel-3-16379.conf > /home/nmc/dev/redis/redis6379/sentinel-3/redis-sentinel-3.log 2>&1 &  


(对于一组Redis master和slave上都启用sentinel,及另外一台机器上再额外启动一个,即最终有三个哨兵)
redis-cli -h 192.168.136.144 -p 16379 sentinel masters 可通过该命令查看当前的master节点情况
redis-cli -p 16379 info 可通过该命令查看master地址,有几个slave,有几个监控
说明:这里第一次操作没有成功,而且杀掉master后,并没有选择出来新的master。检查后,发现配置文件错误,需要重新修改配置文件,redis 实例中的conf 文件,要确定 protected-mode no ,sentinel的conf文件中,也要手工加上 protected-mode no 
  

启动完成后,我们可以查看redis实例的情况

144 主机上,查看info显示redis为 master

Redis实践(二)高可用的集群+哨兵部署_第3张图片
155主机,显示为slave

Redis实践(二)高可用的集群+哨兵部署_第4张图片

我们在155 可以查询key value,但是无法设置值



 四、高可用验证

验证场景:

1) 我们先杀掉master,观察哨兵日志,是否进行了选举,重新选slave为master

通过  redis-cli -h 192.168.136.144  -p 6379  shutdown  命令杀掉  144 master

Redis实践(二)高可用的集群+哨兵部署_第5张图片

2)登录155,查看info信息,并在155 设置新的 key value:(color2 green) (color3  green)。

Redis实践(二)高可用的集群+哨兵部署_第6张图片

3)重启144, 观察是否变为slave

Redis实践(二)高可用的集群+哨兵部署_第7张图片

而且可以获取前面进程失效时, 155 设置的新的key和value


4)杀掉155的master,观察144是否重新变成了master

Redis实践(二)高可用的集群+哨兵部署_第8张图片

说明只要2台redis 不同时故障,redis的高可用是可以达到的。

你可能感兴趣的:(redis)