Redis实践（二）高可用的集群+哨兵部署

小鱼儿 2022-07-15 10:18 287阅读 0赞

项目中通常会需要若干台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 整体部署图如下：

![Center][]

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  
![Center 1][]  
  
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.3Redis 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

![Center 2][]  
155主机，显示为slave

![Center 3][]  
  
我们在155 可以查询key value，但是无法设置值

![Center 4][]

#  四、高可用验证 #

验证场景：

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

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

![Center 5][]

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

![Center 6][]

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

![Center 7][]

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

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

![Center 8][]

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

[Center]: /images/20220715/04d6c43bc32f40458ed278a97fa51585.png
[Center 1]: /images/20220715/eb74bb4fa9b7438aa8a692432c8a9541.png
[Center 2]: /images/20220715/12339201b28c4cbb8e6511595dc47b19.png
[Center 3]: /images/20220715/9184b617161f48b9972b0105a24f68d4.png
[Center 4]: /images/20220715/02a58223a7014bd9aeb67bc8044dd77c.png
[Center 5]: /images/20220715/e78d8cd335b8477b9563e0dd5bd745b7.png
[Center 6]: /images/20220715/f4a7016f2eff418887db3f8a73db8091.png
[Center 7]: /images/20220715/425a96c3c01449619eb8573dae2548a8.png
[Center 8]: /images/20220715/027d85f70c03464b930c649c9e5a3e7a.png