摘要
现阶段的Redis集群主要有两种，一种是高可用集群，Redis Sentinel，一主多从架构，每个实例都持有完整的数据。另一种是分布式集群，Redis Cluster，多主架构，数据分布在各个实例之间，每个实例都负责数据的读写。今天我们来看看Redis Sentinel的搭建过程。
Sentinel
功能
Redis 的 Sentinel 系统用于管理多个 Redis 服务器， 该系统执行以下三个任务：
- 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
- 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
- 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
性质
Sentinel是一个分布式系统，Sentinel本身设计为在有多个Sentinel进程协同合作的配置中运行。优点如下：
- 多个Sentinel投票决定Master的自动故障转移，降低误判率；
- 如果故障转移系统是单点的，那个整个系统无法达到高可用。
部署前需要了解的基本知识
运行Sentinel时必须使用配置文件，否则Sentinel只会拒绝启动。
Sentinels默认情况下会监听TCP端口26379的连接，因此，要使Sentinels正常工作，服务器的端口26379 必须打开才能从其他Sentinel实例的IP地址接收连接。!!!这一点十分重要!!!
-
一个健壮的系统至少需要三个Sentinel实例。
-
应将三个Sentinel实例放置到独立的计算机或虚拟机中。
-
因为Redis使用异步复制，所以Sentinel + Redis高可用方案。有关异步复制的内容可以参考《浅析Redis复制过程》。
-
客户端必须支持Sentinel。
环境
- CentOS 7
- Redis4.0.14
- 虚拟机
部署架构图
部署过程
整体部署过程为先部署上图下半部分的主从集群，再部署sentinel集群。
部署主从集群
分别在Master、Slave1、Slave2下载redis，存放路径 /usr/redis/
[root@localhost ~]wget -P /usr/redis/ http://download.redis.io/releases/redis-4.0.14.tar.gz
分别解压下载好的文件，并安装
[root@localhost ~]cd /usr/redis/
[root@localhost redis]gunzip redis-4.0.14.tar.gz
[root@localhost redis]tar -xvf redis-4.0.14.tar
[root@localhost redis]cd redis-4.0.14
[root@localhost redis-4.0.14]make install
配置Slave1、Slave2的redis.conf文件，让Slave1、Slave2能从Master中复制数据，复制的原理可参考浅析Redis复制过程。下面给出主从集群所需的最少配置：
# slaveof <masterip> <masterport>
slaveof 192.168.33.160 6379
# masterauth <master-password>
masterauth 123456
#默认，推荐设置，slave设置只读
slave-read-only yes
#bind 127.0.0.1 允许其他机器访问
bind 0.0.0.0
#daemonize no 后台运行
daemonize yes
分别启动Master，Slave1，Slave2
[root@localhost redis-4.0.14]cd /src
[root@localhost src]./redis-server ../redis.conf
连上Master，并在上面set一些值，看看同步情况
[root@localhost src]./redis-cli
127.0.0.1:6379>set key1 value1
"ok"
127.0.0.1:6379>quit
连上Slave1，Slave2，尝试着获取key1的值
[root@localhost src]./redis-cli
127.0.0.1:6379>get key1
"value1"
127.0.0.1:6379>quit
至此，主从同步已经部署完成，就下来我们来部署sentinel集群。
部署sentinel集群
Sentinel安装在和Redis同一台机器上，对应的关系如下表：
| Host | Redis | Sentinel |
|---|---|---|
| [Host1]192.168.33.4 | Master | Sentinel1 |
| [Host2]192.168.33.5 | Slave1 | Sentinel2 |
| [Host3]192.168.33.6 | Slave2 | Sentinel3 |
由于Sentinel已经包含在Redis 2.8.0以上的版本中，所以我们可以直接使用之前下载好的redis-4.0.14部署。
分别在Master、Slave1、Slave2对应机器上配置sentinel.conf，下面给出sentinel集群所需的最少配置：
sentinel monitor mymaster 192.168.33.4 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
#后台启动
daemonize yes
#记录日志
logfile "/usr/redis/redis-4.0.14/sentinel_log.log"
#允许其他机器访问,特别要保证sentinel集群之间的机器能够相互访问
bind 0.0.0.0
#关闭保护模块，方便测试
protected-mode no
说明：
- monitor：配置指示 Sentinel 去监视一个名为 mymaster 的主服务器 IP 地址为 127.0.0.1 端口号为 6379 主服务器判断为失效至少需要 2 个 Sentinel 同意（无论你设置要多少个 Sentinel 同意才能判断一个服务器失效， 一个 Sentinel 都需要获得系统中多数Sentinel 的支持， 才能发起一次自动故障迁移）。
- down-after-milliseconds：Sentinel 认为服务器已经断线所需的毫秒数。
- parallel-syncs：选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。
分别启动Master，Slave1，Slave2上的sentinel
[root@localhost src]./redis-server ../sentinel.conf --sentinel
至此，sentinel集群已搭建完毕。
测试
测试一下sentinel集群的故障转移能力：
-
关闭Master进程，其中7081为Master的进程号：
[root@localhost ~]ps -ef | grep redis [root@localhost ~]kill -s 9 7081 -
观察sentinel的日志：
说明：- +sdowm master ，表示Master主观下线；
- +odown master，表示Master客观下线；
- +switch-master ，表示重现选举master;
-
现在192.168.33.6的redis被选举为Master，即Slave2，现在我们尝试在新的Masert（Slave2）上操作，看看能否同步到Slave1上：
#进入新的Masert（Slave2） [[email protected] src]./redis-cli 127.0.0.1:6379>set key2 value2 "ok" -
我们登录到192.168.33.5的redis（Slave1）中，看看是否能够取到key2的值：
#进入Slave1 [[email protected] src]./redis-cli 127.0.0.1:6379>get key2 "value2"我们可以清楚到看到，能够在Slave1中取到新的Masert（Slave2）新插入的值，所以sentinel成功的完成了一次故障转移。
参考
