目录

一  利用docker搭建环境

板书:

一)准备⼯作:

板书:

解读docker配置文件:

1)安装docker和docker-compose

 2) 停⽌之前的redis-server

 3) 使⽤docker获取redis镜像

二)编排redis主从节点

板书:​编辑

1) 编写docker-compose.yml

2) 启动所有容器

3) 查看运⾏⽇志

4) 验证

三)编排 redis-sentinel节点

板书:

1) 编写 docker-compose.yml

 2) 创建配置⽂件

 3) 启动所有容器

 4) 查看运⾏⽇志

5) 观察redis-sentinel 的配置rewrite

二  哨兵自动选举详解

自动选举的全部板书:

1)手动操作观察重新选举

2)选举原理

1) 主观下线

2) 客观下线

 3) 选举出哨兵的leader

 4) leader 挑选出合适的slave成为新的 master

三  总结

---

一  利用docker搭建环境

板书:

一)准备⼯作:

板书:

解读docker配置文件:

 

1)安装docker和docker-compose

关于docker的安装请点击链接看docker专栏

docker-compose安装

 # ubuntuapt install docker-compose# centosyum install docker-compose

 2) 停⽌之前的redis-server

# 停⽌redis-server
service redis-server stop
# 停⽌redis-sentinel 如果已经有的话
service redis-sentinel stop

 3) 使⽤docker获取redis镜像

docker pull redis:5.0.9

二)编排redis主从节点

复制粘贴的格式可能不对,需要正确格式的私聊我

板书:

1) 编写docker-compose.yml

创建 /root/redis/docker-compose.yml ,同时cd到yml所在⽬录中.

注意:docker中可以通过容器名字,作为ip地址,进⾏相互之间的访问

 version: '3.7'services:master:image: 'redis:5.0.9'container_name: redis-masterrestart: alwayscommand: redis-server --appendonly yesports: - 6379:6379slave1:image: 'redis:5.0.9'container_name: redis-slave1restart: alwayscommand: redis-server --appendonly yes --slaveof redis-master 6379ports:- 6380:6379slave2:image: 'redis:5.0.9'container_name: redis-slave2restart: alwayscommand: redis-server --appendonly yes --slaveof redis-master 6379ports:- 6381:6379

2) 启动所有容器

docker-compose up -d

如果启动后发现前⾯的配置有误,需要重新操作,使⽤ docker-compose down 即可停⽌并删除刚才创建好的容器.

3) 查看运⾏⽇志

docker-compose logs

上 述操作必须保证⼯作⽬录在yml的同级⽬录中,才能⼯作

4) 验证

连接主节点  redis-cli -p 6379

 127.0.0.1:6379> info replication# Replicationrole:masterconnected_slaves:2slave0:ip=172.22.0.3,port=6379,state=online,offset=348,lag=1slave1:ip=172.22.0.4,port=6379,state=online,offset=348,lag=1master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63master_replid2:0000000000000000000000000000000000000000master_repl_offset:348second_repl_offset:-1repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:1repl_backlog_histlen:348

连接从节点  redis-cli -p 6380

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:redis-master
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:446
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:446
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:446

连接从节点  redis-cli -p 6381

 127.0.0.1:6381> info replication# Replicationrole:slavemaster_host:redis-mastermaster_port:6379master_link_status:upmaster_last_io_seconds_ago:7master_sync_in_progress:0slave_repl_offset:516slave_priority:100slave_read_only:1connected_slaves:0master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63master_replid2:0000000000000000000000000000000000000000master_repl_offset:516second_repl_offset:-1repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:1repl_backlog_histlen:516

三)编排 redis-sentinel节点

复制粘贴的格式可能不对,需要正确格式的私聊我

板书:

也可以把redis-sentinel放到和上⾯的redis的同⼀个yml中进⾏容器编排.此处分成两组,主要是为
了两⽅⾯:

• 观察⽇志⽅便
• 确保redis主从节点启动之后才启动redis-sentinel.如果先启动redis-sentinel的话,可能触发额 外的选举过程,混淆视听.(不是说先启动哨兵不⾏,⽽是观察的结果可能存在⼀定随机性).

1) 编写 docker-compose.yml

创建 /root/redis-sentinel/docker-compose.yml ,同时cd到yml所在⽬录中.

注意:每个⽬录中只能存在⼀个docker-compose.yml⽂件.

version: '3.7'
services:sentinel1:image: 'redis:5.0.9'container_name: redis-sentinel-1restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel1.conf:/etc/redis/sentinel.confports:- 26379:26379
sentinel2:image: 'redis:5.0.9'container_name: redis-sentinel-2restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel2.conf:/etc/redis/sentinel.confports:- 26380:26379
sentinel3:image: 'redis:5.0.9'container_name: redis-sentinel-3restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel3.conf:/etc/redis/sentinel.confports:- 26381:26379
networks:default:external:name: redis-data_default 

 2) 创建配置⽂件

创建 sentinel1.conf sentinel2.conf sentinel3.conf 三份文件的内容是完全相同的,都放到 /root/redis-sentinel/ ⽬录中.

bind 0.0.0.0
port 26379
sentinel monitor redis-master redis-master 6379 2
sentinel down-after-milliseconds redis-master 1000

理解 sentinel monitor

sentinel monitor 主节点名 主节点 ip 主节点端⼝ 法定票数

参数解释:

• 主节点名,这个是哨兵内部⾃⼰起的名字
• 主节点ip,部署redis-master的设备ip.此处由于是使⽤docker,可以直接写docker的容器名,会被⾃动DNS成对应的容器ip
• 主节点端⼝,不解释.
• 法定票数,哨兵需要判定主节点是否挂了.但是有的时候可能因为特殊情况,⽐如主节点仍然⼯作正常,但是哨兵节点⾃⼰⽹络出问题了,⽆法访问到主节点了.此时就可能会使该哨兵节点认为主节点下线,出现误判.使⽤投票的⽅式来确定主节点是否真的挂了是更稳妥的做法.需要多个哨兵都认为主节点挂了,票数>=法定票数之后,才会真的认为主节点是挂了.

理解 sentinel down-after-milliseconds

主节点和哨兵之间通过⼼跳包来进⾏沟通.如果⼼跳包在指定的时间内还没回来,就视为是节点出现 故障.

既然内容相同,为啥要创建多份配置⽂件?

redis-sentinel 在运⾏中可能会对配置进⾏rewrite,修改⽂件内容.如果⽤⼀份⽂件,就可能出现修改混乱的情况.

 3) 启动所有容器

 docker-compose up -d

如果启动后发现前⾯的配置有误,需要重新操作,使⽤ docker-compose down 刚才创建好的容器.

 4) 查看运⾏⽇志

 docker-compose logs

上述操作必须保证⼯作⽬录在yml的同级⽬录中,才能⼯作.

可以看到,哨兵节点已经通过主节点,认识到了对应的从节点.

5) 观察redis-sentinel 的配置rewrite

再次打开哨兵的配置⽂件,发现⽂件内容已经被⾃动修改了.

 bind 0.0.0.0port 26379sentinel myid 4d2d562860b4cdd478e56494a01e5c787246b6aasentinel deny-scripts-reconfig yes# Generated by CONFIG REWRITEdir "/data"sentinel monitor redis-master 172.22.0.4 6379 2sentinel down-after-milliseconds redis-master 1000sentinel config-epoch redis-master 1sentinel leader-epoch redis-master 1sentinel known-replica redis-master 172.22.0.2 6379sentinel known-replica redis-master 172.22.0.3 6379sentinel known-sentinel redis-master 172.22.0.7 26379 f718caed536d178f5ea6d1316d09407cfae43dd2sentinel known-sentinel redis-master 172.22.0.5 26379 2ab6de82279bb77f8397c309d36238f51273e80asentinel current-epoch 1

# Generated by CONFIG REWRITE 这⾥的内容就是⾃动修改的

对⽐这三份⽂件,可以看到配置内容是存在差异的

二  哨兵自动选举详解

自动选举的全部板书:

1)手动操作观察重新选举

redis-master 宕机之后

⼿动把 redis-master ⼲掉

1 docker stop redis-master

观察哨兵的⽇志

可以看到哨兵发现了主节点sdown,进⼀步的由于主节点宕机得票达到 master 被判定为odown.

• 主观下线(SubjectivelyDown,SDown):哨兵感知到主节点没⼼跳了.判定为主观下线
• 客观下线(ObjectivelyDown,ODown):多个哨兵达成⼀致意⻅,才能认为master确实下线了.

接下来,哨兵们挑选出了⼀个新的master.在上图中,是172.22.04:6379 这个节点.

此时,对于Redis来说仍然是可以正常使⽤的.

redis-master 重启之后

⼿动把 redis-master 启动起来

1 docker start redis-master

观察哨兵⽇志可以看到刚才新启动的redis-master 被当成了slave

使⽤redis-cli 也可以进⼀步的验证这⼀点

 127.0.0.1:6379> info replication# Replicationrole:slavemaster_host:172.22.0.4master_port:6379master_link_status:upmaster_last_io_seconds_ago:0master_sync_in_progress:0slave_repl_offset:324475slave_priority:100slave_read_only:1connected_slaves:0master_replid:ececc285a2892fba157318c77ebe1409f9c2254emaster_replid2:0000000000000000000000000000000000000000master_repl_offset:324475second_repl_offset:-1repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:318295repl_backlog_histlen:6181

结论

•  Redis主节点如果宕机,哨兵会把其中的⼀个从节点,提拔成主节点.
• 当之前的Redis主节点重启之后,这个主节点被加⼊到哨兵的监控中,但是只会被作为从节点使⽤

2)选举原理

假定当前环境如上⽅介绍,三个哨兵(sentenal1,sentenal2,sentenal3),⼀个主节点(redis-master),两
个从节点(redis-slave1,redis-slave2). 
当主节点出现故障,就会触发重新⼀系列过程.

1) 主观下线

当redis-master 宕机,此时redis-master和三个哨兵之间的⼼跳包就没有了.
此时,站在三个哨兵的⻆度来看,redis-master出现严重故障.因此三个哨兵均会把redis-master判定
为主观下线(SDown)

2) 客观下线

此时,哨兵sentenal1,sentenal2,sentenal3均会对主节点故障这件事情进⾏投票.当故障得票数>=配
置的法定票数之后,

 sentinel monitor redis-master 172.22.0.4 6379 2

 3) 选举出哨兵的leader

接下来需要哨兵把剩余的slave中挑选出⼀个新的master.这个⼯作不需要所有的哨兵都参与.只需要选出个代表(称为leader),由leader负责进⾏slave升级到master的提拔过程.这个选举的过程涉及到 Raft 算法

假定一共三个哨兵结点 S1 S2 S3

1. 每个哨兵节点都给其他所有哨兵节点,发起⼀个"拉票请求".(S1->S2,S1->S3,S2->S1,S2->S3,S3->S1,S3->S2)

2. 收到拉票请求的节点,会回复⼀个"投票响应".响应的结果有两种可能,投or不投.

        ⽐如S1给S2发了个投票请求,S2就会给S1返回投票响应.
        到底S2是否要投S1呢?取决于S2是否给别⼈投过票了.(每个哨兵只有⼀票).
        如果S2没有给别⼈投过票,换⽽⾔之,S1是第⼀个向S2拉票的,那么S2就会投S1.否则则不投.

3. ⼀轮投票完成之后,发现得票超过半数的节点,⾃动成为leader0.

        如果出现平票的情况(S1投S2,S2投S3,S3投S1,每⼈⼀票),就重新再投⼀次即可. 这也是为啥建议哨兵节点设置成奇数个的原因.如果是偶数个,则增⼤了平票的概率,带来不必要的开销.

 4. leader 节点负责挑选⼀个slave成为新的master.当其他的sentenal发现新的master出现了,就说明选举结束了.

简⽽⾔之,Raft算法的核⼼就是"先下⼿为强".谁率先发出了拉票请求,谁就有更⼤的概率成为leader

这⾥的决定因素成了"⽹络延时".⽹络延时本⾝就带有⼀定随机性

具体选出的哪个节点是leader,这个不重要,重要的是能选出⼀个节点即可.        

 4) leader 挑选出合适的slave成为新的 master

挑选规则:

 1. ⽐较优先级.优先级⾼(数值⼩的)的上位.优先级是配置⽂件中的配置项(slave-priority)或者(replica-priority)

2. ⽐较 replication offset 谁复制的数据多,⾼的上位.

3. ⽐较run id ,谁的id⼩,谁上位.

当某个slave节点被指定为master之后,

1. leader 指定该节点执⾏slave no one ,成为master

2. leader 指定剩余的slave节点,都依附于这个新master

三  总结

上述过程,都是"⽆⼈值守",Redis⾃动完成的.这样做就解决了主节点宕机之后需要⼈⼯⼲预的问题,
提⾼了系统的稳定性和可⽤性.

⼀些注意事项:

•  哨兵节点不能只有⼀个.否则哨兵节点挂了也会影响系统可⽤性.
•  哨兵节点最好是奇数个.⽅便选举leader,得票更容易超过半数.
•  哨兵节点不负责存储数据.仍然是redis主从节点负责存储.
•  哨兵+主从复制解决的问题是"提⾼可⽤性",不能解决"数据极端情况下写丢失"的问题
•  哨兵+主从复制不能提⾼数据的存储容量.当我们需要存的数据接近或者超过机器的物理内存,这样的结构就难以胜任了.

为了能存储更多的数据,就引⼊了集群.