高可用的redis服务搭建

Redis Sentinel 介绍与部署

1. Sentinel介绍

1.1 主从复制的问题

Redis主从复制可将主节点数据同步给从节点，从节点此时有两个作用：

一旦主节点宕机，从节点作为主节点的备份可以随时顶上来。
扩展主节点的读能力，分担主节点读压力。

但是问题来了：

一旦主节点宕机，从节点晋升成主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。
主节点的写能力受到单机的限制。
主节点的存储能力受到单机的限制。

第一个问题，我们接下来讲的Sentinel就可以解决。而后两个问题，Redis也给出了方案Redis Cluster。

1.2 Redis Sentinel的高可用

Redis Sentinel是一个分布式架构，包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当发现节点不可达时，会对节点做下线标识。

如果被标识的是主节点，他还会选择和其他Sentinel节点进行“协商”，当大多数的Sentinel节点都认为主节点不可达时，他们会选举出一个Sentinel节点来完成自动故障转移工作，同时将这个变化通知给Redis应用方。

整个过程完全自动，不需要人工介入，所以可以很好解决Redis的高可用问题。

接下来我们就通过部署一个Redis Sentinel实例来了解整体框架。

2. Redis Sentinel部署

我们部署的拓扑结构如图所示：

拓扑结构

分别有3个Sentinel节点，1个主节点，2个从节点组成一个Redis Sentinel。

role	IP	port
master	127.0.0.1	6379
slave1	127.0.0.1	6380
slave2	127.0.0.1	6381
Sentinel1	127.0.0.1	26379
Sentinel2	127.0.0.1	26380
Sentinel3	127.0.0.1	26381

2.1 启动主节点

配置：

port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
#这个文件路径是你自己要创建的，redis服务数据存放的位置。
dir "/home/redis3.0.0/data/"

启动主节点

sudo redis-server redis-6379.conf

使用PING命令检测是否启动

redis-cli -h 127.0.0.1 -p 6379 ping
#如果出现PONG，表示服务有效

2.2 启动两个从节点

配置（两个从节点配置相同，除了文件名有区分）

port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/home/redis3.0.0/data/"
slaveof 127.0.0.1 6379      // 从属主节点

port 6381
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/home/redis3.0.0/data/"
slaveof 127.0.0.1 6379      // 从属主节点

启动两个从节点

  sudo redis-server redis-6380.conf 
  sudo redis-server redis-6381.conf

使用PING命令检测是否启动

redis-cli -h 127.0.0.1 -p 6380 ping
redis-cli -h 127.0.0.1 -p 6381 ping

2.3 确认主从关系

主节点视角

➜   redis-cli -h 127.0.0.1 -p 6379 INFO replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=85,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=85,lag=0
......

从节点视角（6380端口）

➜   redis-cli -h 127.0.0.1 -p 6380 INFO replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
......

确立中从关系，如下图所示：

这里写图片描述

2.4 部署Sentinel节点

3个Sentinel节点的部署方法是相同的（端口不同）。以26379为例。

配置

// Sentinel节点的端口
port 26379  
dir /var/redis/data/
logfile "26379.log"

// 当前Sentinel节点监控 127.0.0.1:6379 这个主节点
// 2代表判断主节点失败至少需要2个Sentinel节点节点同意
// mymaster是主节点的别名
sentinel monitor mymaster 127.0.0.1 6379 2

//每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过30000毫秒且没有回复，则判定不可达
sentinel down-after-milliseconds mymaster 30000

//当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1
sentinel parallel-syncs mymaster 1

//故障转移超时时间为180000毫秒
sentinel failover-timeout mymaster 180000

启动
- redis-sentinel sentinel-26379.conf

sudo nohup redis-sentinel sentinel-26379.conf  &

注意：nohup command &可以保证在让程序在后台启动的同时当你关闭总端时不挂起。

确认

➜   redis-cli -h 127.0.0.1 -p 26379 INFO Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=1 //sentinels=1表示启动了1个Sentinel

部署三个Sentinel节点之后，真个拓扑结构如图所示：

这里写图片描述

当部署号Redis Sentinel之后，会有如下变化
- Sentinel节点自动发现了从节点、其余Sentinel节点。
- 去掉了默认配置，例如：parallel-syncs、failover-timeout。
- 新添加了纪元（epoch）参数。

我们拿端口26379的举例，启动所有的Sentinel和数据节点后，配置文件如下：

port 26379
dir "/var/redis/data"
sentinel myid 70a3e215c1a34b4d9925d170d9606e615a8874f2
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
daemonize yes
logfile "26379.log"
// 发现了两个从节点
sentinel known-slave mymaster 127.0.0.1 6381
sentinel known-slave mymaster 127.0.0.1 6380
// 发送了连个Sentinel节点
sentinel known-sentinel mymaster 127.0.0.1 26381 e1148ad6caf60302dd6d0dbd693cb3448e209ac2
sentinel known-sentinel mymaster 127.0.0.1 26380 39db5b040b21a52da5334dd2d798244c034b4fc3
sentinel current-epoch 0

2.5 故障转移实验

先查看一下节点的进程pid

➜   ps -aux | grep redis
root      5422  0.0  0.3  71328  3980 pts/9    T    11:54   0:00 sudo nohup redis-sentinel sentinel-26379.conf
root      5458  0.7  0.9  42304  9488 pts/9    Sl   11:59   0:00 redis-sentinel *:26380 [sentinel] 
root      5463  0.8  0.9  42304  9400 pts/9    Sl   11:59   0:00 redis-sentinel *:26381 [sentinel] 
root      5468  0.3  0.8  42304  9016 ?        Ssl  12:00   0:00 redis-server *:6379         
root      5472  0.2  0.9  42304  9104 ?        Ssl  12:00   0:00 redis-server *:6380         
root      5476  0.4  0.8  42304  9044 ?        Ssl  12:00   0:00 redis-server *:6381         
root      5482  0.0  0.2  15964  2056 pts/9    S+   12:01   0:00 grep --color=auto redis

我们干掉端口6379的主节点。

➜   sudo kill -9 5468
➜   ps -aux | grep redis
root      5422  0.0  0.3  71328  3980 pts/9    T    11:54   0:00 sudo nohup redis-sentinel sentinel-26379.conf
root      5458  0.6  0.9  42304  9488 pts/9    Sl   11:59   0:01 redis-sentinel *:26380 [sentinel] 
root      5463  0.6  0.9  42304  9400 pts/9    Sl   11:59   0:01 redis-sentinel *:26381 [sentinel] 
root      5472  0.1  0.9  42304  9104 ?        Ssl  12:00   0:00 redis-server *:6380         
root      5476  0.1  1.0  42304 11092 ?        Ssl  12:00   0:00 redis-server *:6381         
root      5484  0.0  0.2  15964  2108 pts/9    S+   12:03   0:00 grep --color=auto redis

此时，Redis Sentinel对主节点进行客观下线（Objectively Down，简称 ODOWN）的判断，确认主节点不可达，则通知从节点中止复制主节点的操作。

这里写图片描述

当主节点下线时长超过配置的下线时长30000秒，Redis Sentinel执行故障转移操作。

此时，我们查看一下Sentinel节点监控的主节点信息：

127.0.0.1:26379> sentinel masters 
1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6380"           //可以看到主节点已经成为6380端口的节点
    7) "runid"
    8) "084850ab4ff6c2f2502b185c8eab5bdd25a26ce2"
    9) "flags"
   10) "master"
    ..............

看一下Sentinel节点监控的从节点信息：

127.0.0.1:26379> sentinel slaves mymaster
1)  1) "name"
    2) "127.0.0.1:6379"             //ip:port
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6379"
    7) "runid"
    8) ""
    9) "flags"
   10) "s_down,slave,disconnected"  //端口6379的原主节点已经断开了连接
   ..............
2)  1) "name"
    2) "127.0.0.1:6381"             
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6381"
    7) "runid"
    8) "24495fe180e4fd64ac47467e0b2652894406e9e4"
    9) "flags"
   10) "slave"                      //本来的从节点，还是从节点的role
    ..............

由以上信息可得，端口为6380的Redis数据节点成为新的主节点，端口为6379的旧主节点断开连接。如图所示：

这里写图片描述

我们在试着重启端口6379的数据节点。

➜   sudo redis-server redis-6379.conf 
➜   ps -aux | grep redis              
root     18234  0.1  0.0  40208 11392 ?        Ssl  5月22   0:06 redis-server 127.0.0.1:6380
root     18244  0.1  0.0  40208 10356 ?        Ssl  5月22   0:07 redis-server 127.0.0.1:6381
root     20568  0.1  0.0  38160  8460 ?        Ssl  5月22   0:05 redis-sentinel *:26379 [sentinel]
root     20655  0.1  0.0  38160  8296 ?        Ssl  5月22   0:05 redis-sentinel *:26380 [sentinel]
root     20664  0.1  0.0  38160  8312 ?        Ssl  5月22   0:05 redis-sentinel *:26381 [sentinel]
menwen   22475  0.0  0.0  14216  5920 pts/2    S+   5月22   0:00 redis-cli -p 26379
// 6379的数据节点已重启
root     22617  0.0  0.0  38160  8304 ?        Ssl  00:00   0:00 redis-server 127.0.0.1:6379

看看发生什么：

127.0.0.1:26379> sentinel slaves mymaster
1)  1) "name"
    2) "127.0.0.1:6379"     //6379端口的节点重启后，变成了"活"的从节点
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6379"
    7) "runid"
    8) "de1b5c28483cf150d9550f8e338886706e952346"
    9) "flags"
   10) "slave"
    ..............
2)  1) "name"               //6381端口的节点没有变化，仍是从节点
    2) "127.0.0.1:6381"
    ..............

他被降级成为端口6380的从节点。

这里写图片描述

从上面的逻辑架构和故障转移试验中，可以看出Redis Sentinel的以下几个功能。

监控：Sentinel节点会定期检测Redis数据节点和其余Sentinel节点是否可达。
通知：Sentinel节点会将故障转移通知给应用方。
主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系。
配置提供者：在Redis Sentinel结构中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息。

3. Sentinel配置说明

sentinel monitor mymaster 127.0.0.1 6379 2
- 当前Sentinel节点监控 127.0.0.1:6379 这个主节点
- 2代表判断主节点失败至少需要2个Sentinel节点节点同意
- mymaster是主节点的别名
sentinel down-after-milliseconds mymaster 30000
- 每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过30000毫秒且没有回复，则判定不可达
sentinel parallel-syncs mymaster 1
- 当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1。
sentinel failover-timeout mymaster 180000
- 故障转移超时时间为180000
sentinel auth-pass \ \
- 如果Sentinel监控的主节点配置了密码，可以通过sentinel auth-pass配置通过添加主节点的密码，防止Sentinel节点无法对主节点进行监控。
- 例如：sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
sentinel notification-script \ \
- 在故障转移期间，当一些警告级别的Sentinel事件发生（指重要事件，如主观下线，客观下线等）时，会触发对应路径的脚本，想脚本发送相应的事件参数。
- 例如：sentinel notification-script mymaster /var/redis/notify.sh
sentinel client-reconfig-script \ \
- 在故障转移结束后，触发应对路径的脚本，并向脚本发送故障转移结果的参数。
- 例如：sentinel client-reconfig-script mymaster /var/redis/reconfig.sh。

参考文献：
http://mp.weixin.qq.com/s/XzVwAoN7K6dDajD9B2q5zg
https://blog.csdn.net/men_wen/article/details/72724406

人面猴
序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
沈念sama阅读 217,509评论 6赞 504
死咒
序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
沈念sama阅读 92,806评论 3赞 394
救了他两次的神仙让他今天三更去死
文/潘晓璐我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
开封第一讲书人阅读 163,875评论 0赞 354
道士缉凶录：失踪的卖姜人
文/不坏的土叔我叫张陵，是天一观的道长。经常有香客问我，道长，这世上最难降的妖魔是什么？我笑而不...
开封第一讲书人阅读 58,441评论 1赞 293
港岛之恋（遗憾婚礼）
正文为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
茶点故事阅读 67,488评论 6赞 392
恶毒庶女顶嫁案：这布局不是一般人想出来的
文/花漫我一把揭开白布。她就那样静静地躺着，像睡着了一般。火红的嫁衣衬着肌肤如雪。梳的纹丝不乱的头发上，一...
开封第一讲书人阅读 51,365评论 1赞 302
城市分裂传说
那天，我揣着相机与录音，去河边找鬼。笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。我是一名探鬼主播，决...
沈念sama阅读 40,190评论 3赞 418
双鸳鸯连环套：你想象不到人心有多黑
文/苍兰香墨我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
开封第一讲书人阅读 39,062评论 0赞 276
万荣杀人案实录
序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
沈念sama阅读 45,500评论 1赞 314
护林员之死
正文独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋以下内容为张勋视角年9月15日...
茶点故事阅读 37,706评论 3赞 335
白月光启示录
正文我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
茶点故事阅读 39,834评论 1赞 347
活死人
序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
沈念sama阅读 35,559评论 5赞 345
日本核电站爆炸内幕
正文年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
茶点故事阅读 41,167评论 3赞 328
男人毒药：我在死后第九天来索命
文/蒙蒙一、第九天我趴在偏房一处隐蔽的房顶上张望。院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
开封第一讲书人阅读 31,779评论 0赞 22
一桩弑父案，背后竟有这般阴谋
文/苍兰香墨我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。一阵脚步声响...
开封第一讲书人阅读 32,912评论 1赞 269
情欲美人皮
我被黑心中介骗来泰国打工，没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。一个月前我还...
沈念sama阅读 47,958评论 2赞 370
代替公主和亲
正文我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
茶点故事阅读 44,779评论 2赞 354

高可用的redis服务搭建

Redis Sentinel 介绍与部署

1. Sentinel介绍

1.1 主从复制的问题

1.2 Redis Sentinel的高可用

2. Redis Sentinel部署

2.1 启动主节点

2.2 启动两个从节点

2.3 确认主从关系

2.4 部署Sentinel节点

2.5 故障转移实验

3. Sentinel配置说明

推荐阅读更多精彩内容