前阵子遇到了一个关于redis宕机的问题，后来经排查是代码不当导致的，处理好该问题后，就产生了另外一个问题——如果redis由于各种原因出现宕机时，如何自动进行故障处理？

其实了解redis的同学肯定都清楚，redis本身支持分布式部署，主要有三种模式，1是主从同步，2是哨兵集群，3是分布式集群。

关于以上几点的详细内容，网上的介绍博客很多，这里有一个我感觉还不错的介绍。

我这里就简单总结一下

主从同步可以做到数据的实时备份和读写分离，但写操作都在主节点上，如果主节点宕机，需要手动切换节点（需要至少2个节点）；

哨兵则是主从同步的增强版，可以自动进行故障转移，当主节点发生故障后，会先尝试重启主节点，操作失败后，会在子节点中选举新的主节点，从而完成故障转移，保证了集群的高可用（推荐3个及以上节点）；

集群模式则是为了解决以上两种模式都无法解决的分布式存储问题，在保证了高可用的基础上，分片存储缓存数据，真正做到分布式存储，性能更高，当然要做集群部署也要满足一定条件，比如至少需要6个redis节点（三主三从），成本相对较高，但这也确实是官方最推荐的模式 >。

由于我们的业务数据规模不大，在权衡之后，我决定先采用部署哨兵集群的模式来小试牛刀，后续如果系统稳定，在进行集群模式的升级，虽然免不了折腾一番，但毕竟实践才是检验真理的唯一标准，只有自己亲自尝试过，才能真正了解不同模式的区别和redis内部的一些运行机制。

好了，话不多说，开整。

一、选环境

在出现节点故障之前，我们的redis采用的是之前微软维护的一个redis分支版本，可以在Windows系统上安装，但最高也只是支持到了3.2.100，且2016年以后，就归档不再更新了。后来有个国外的老哥，自己维护了一个redis for windows的版本：，看到star数也挺多，应该也是比较受欢迎的。

我还是决定采用官方的版本，这就跟买东西一样，品牌的力量还是很重要的。

我这里用的是Ubuntu 20.0.14+redis-6.2.5

redis的安装，官网有详细介绍，我自己之前也写过一篇相关的介绍，就不多说了。

二、编写redis配置文件

1.编写redis.conf

我采用了一主二从三哨兵的模式进行的部署，所以要编写3个redis.conf文件

这里建议在系统里划出独立的目录来管理

#存储节点配置文件(一主二从)
sudo mkdir -p /etc/redis/master
sudo mkdir -p /etc/redis/slave1
sudo mkdir -p /etc/redis/slave2
#存储日志
sudo mkdir -p /usr/local/redis-6.2.5/log

分别存储主节点和从节点的配置文件

安装好redis之后，可以把安装目录下的redis.conf分别复制3份到以上3个目录，当然也可以直接touch新文件把需要的配置写进去，毕竟默认的redis.conf里有很多的注释。但我个人还是建议复制安装目录下的文件，可以详细了解下每个配置项都是干什么的。

sudo sudo cp /home/tony/redis/redis-6.2.5/redis.conf /etc/redis/master

先复制一份，然后在vim/vi编辑器下找到以下配置并修改好

#这个是主节点的配置

#开放ip，默认是127.0.0.1，可以这么写，也可以直接注释掉默认的那个
bind 0.0.0.0
#端口
port 6380
#守护进程，也就是后台启动，启动会不会出现那个标志性图案
daemonize yes
#客户端连接密码
requirepass wt123456
#日志路径
logfile "/usr/local/redis-6.2.5/log/redis1.log"
#快照
dbfilename "master.rdb"
appendonly yes
#这个是aof日志，增量备份用到
appendfilename "master.aof"
#哨兵授权密码，怕弄混就设置成一样的
masterauth wt123456

然后复制到两个从节点目录

sudo sudo cp /etc/redis/master/redis.conf /etc/redis/slave1/
sudo sudo cp /etc/redis/master/redis.conf /etc/redis/slave2/

之后分别修改两个配置文件，增加关键配置

#这个是从节点1的配置
bind 0.0.0.0
port 6381
daemonize yes
requirepass wt123456
logfile "/usr/local/redis-6.2.5/log/redis2.log"
dbfilename "slave1.rdb"
appendonly yes
appendfilename "slave1.aof"
#应该是5.0版本以后采用replicaof，之前是slaveof，为了维护黑人权利而修改的关键命令~~
replicaof 127.0.0.1 6380
masterauth wt123456

同样的从节点2的配置和1类似

#这个是从节点1的配置
bind 0.0.0.0
port 6382
daemonize yes
requirepass wt123456
logfile "/usr/local/redis-6.2.5/log/redis3.log"
dbfilename "slave2.rdb"
appendonly yes
appendfilename "slave2.aof"
#应该是5.0版本以后采用replicaof，之前是slaveof，为了维护黑人权利而修改的关键命令~~
replicaof 127.0.0.1 6380
masterauth wt123456

配置完成后，启动服务

sudo /home/tony/redis/redis-6.2.5/src/redis-server /etc/redis/master/redis.conf
sudo /home/tony/redis/redis-6.2.5/src/redis-server /etc/redis/slave1/redis.conf
sudo /home/tony/redis/redis-6.2.5/src/redis-server /etc/redis/slave2/redis.conf

启动后，查看运行状态

sudo src/redis-cli -p 6380

从打印出来的信息，可以看到当前节点的角色，子节点信息等内容（因为我这个是故障转移过一次了，所以主节点有6380变成了6381）

至此也就完成了主从同步的配置流程。

可以在终端或者redis客户端尝试在主节点写入一个键值，会看到从节点也会同步该键值

三、编写哨兵配置文件

redis的安装文件里也有默认的哨兵配置文件，这里也采用和设置redis配置文件类似的方式，将该文件分别复制到指定的目录（我这里偷了个懒，直接touch了新文件进行的复制，结果是一样的）

#创建sentinel目录
sudo mkdir -p /etc/redis/sentinel
#创建哨兵配置文件
sudo touch sentinel1.conf
#编写关键配置内容
sudo vim sentinel1.conf
#写入以下内容
port 26380
bind 0.0.0.0
daemonize yes
pidfile "/var/run/redis-sentinel-1.pid"
logfile "/var/log/redis/sentinel_26380.log"
dir "/tmp"
sentinel monitor mymaster 127.0.0.1 6380 2

sentinel auth-pass mymaster wt123456
sentinel failover-timeout mymaster 60000

保存后，复制sentinel1.conf到sentinel2.conf和sentinel3.conf

cp sentinel1.conf sentinel2.conf
cp sentinel1.conf sentinel3.conf

修改对应的端口号内容不在贴图

然后启动哨兵

sudo src/redis-server /etc/redis/sentinel/sentinel1.conf --sentinel
sudo src/redis-server /etc/redis/sentinel/sentinel2.conf --sentinel
sudo src/redis-server /etc/redis/sentinel/sentinel3.conf --sentinel

启动后，可实时查看哨兵日志内容

tail -fn 300 /var/log/redis/sentinel_26380.log

验证哨兵内容

sudo src/redis-cli -p 26380

至此哨兵的环境就搭建好了，接下来可以验证下主动宕机一下主节点

然后观察下哨兵日志

可以看到，哨兵在检测到主节点下线后，会尝试重启主节点，再确认主节点挂掉之后，会在子节点中进行选举，选举出新的主节点，从而完成了故障转移。

再次重启挂掉的节点后，该节点自动成为新的子节点

好了，哨兵的部署先写到这，下来有时间在结合代码来说一下怎么在代码里搭配哨兵集群与系统业务相结合。