摘要
现阶段的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成功的完成了一次故障转移。