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 整体部署图如下：

      


         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在主从复制时，需要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   root@192.168.136.144:/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



155主机，显示为slave



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

 四、高可用验证

验证场景：

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

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



2）登录155，查看info信息，并在155 设置新的 key value：（color2 green） （color3  green）。



3）重启144， 观察是否变为slave



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

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



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