Redis의 Sentinel 모드를 분석하고 구축 및 실행 프로세스에 대해 이야기합니다.-Redis-php.cn

이 글은 Redis의 센티넬 모드에 대한 심층적인 이해를 제공하고, 센티넬 모드 구축 단계, 실행 프로세스, 센티넬 선택을 소개하는 글이 모든 분들께 도움이 되기를 바랍니다!

Redis의 Sentinel 모드를 분석하고 구축 및 실행 프로세스에 대해 이야기합니다.

기본 소개

Sentinel은 Redis용 고가용성(High Availability) 솔루션입니다.

Sentinel 클러스터는 하나 이상의 마스터 서버와 여러 슬레이브 서버를 모니터링할 수 있습니다. [관련 권장 사항: Redis 동영상 튜토리얼]
메인 서버가 오프라인 상태가 되면 Sentinel은 메인 서버 아래의 슬레이브 서버를 업그레이드하여 메인 서버에 계속 서비스를 제공함으로써 Redis의 고가용성을 보장할 수 있습니다.
Illustration

Redis의 Sentinel 모드를 분석하고 구축 및 실행 프로세스에 대해 이야기합니다.

Sentinel 모드 구축 단계

1 sentinel.conf 파일 복사

cp sentinel.conf sentinel‐26379.conf
cp sentinel.conf sentinel‐26380.conf
cp sentinel.conf sentinel‐26381.conf

로그인 후 복사

#哨兵sentinel实例运行的端口默认26379
port 26379

#将`daemonize`由`no`改为`yes`
daemonize yes

#哨兵sentinel监控的redis主节点的 ip port
#master-name可以自己命名的主节点名字只能由字母A-z、数字0-9、这三个字符".-_"组成。#quorum当这些quorum个数sentinel哨兵认为master主节点失联那么这时客观上认为主节点失联了
#sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor master 127.0.0.1 6379 2

#当在Redis实例中开启了requirepass foobared授权密码这样所有连接Redis实例的客户端都要提供密码
#设置哨兵sentinel连接主从的密码注意必须为主从设置一样的验证密码
#sentinel auth-pass <master-name> <password>

sentinel auth-pass master MySUPER--secret-0123passw0rd

#指定多少毫秒之后主节点没有应答哨兵sentinel此时哨兵主观上认为主节点下线默认30秒，改成3秒
#sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds master 3000

#这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。可以通过将这个值设为1来保证每次只有一个slave处于不能处理命令请求的状态。
#sentinel parallel-syncs <master-name> <numslaves>

sentinel parallel-syncs master 1

#故障转移的超时时间failover-timeout可以用在以下这些方面：
#1.同一个sentinel对同一个master两次failover之间的间隔时间。
#2.当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了#默认三分钟
#sentinel failover-timeout <master-name> <milliseconds>
sentinelf ailover-timeout master1 80000

로그인 후 복사

rrree

3、 시작 sentinel 인스턴스

#redis-master 및 redis-slaver 시작

docker run -it --name redis-sentinel2639  -v /Users/yujiale/docker/redis/conf/sentinel6379.conf:/etc/redis/sentinel.conf -v /Users/yujiale/docker/redis/data26379:/data --network localNetwork --ip 172.172.0.16 -d redis:6.2.6 redis-sentinel /etc/redis/sentinel.conf

로그인 후 복사

#redis-sentinel 시작

在redis-master目录下  ./redis-server redis.conf
在redis-slaver1目录下 ./redis-server redis.conf
在redis-slaver2目录下 ./redis-server redis.conf

로그인 후 복사

4 시작 상태를 확인하세요

Redis의 Sentinel 모드를 분석하고 구축 및 실행 프로세스에 대해 이야기합니다.

실행 프로세스

1. Sentinel 시작 및 초기화

Sentinel은 지속되지 않는 특별한 Redis 서버입니다

Sentinel 인스턴스가 시작된 후 각 Sentinel은 기본 서버에 대한 2개의 네트워크 연결을 생성합니다

명령 연결: 다음에 연결하는 데 사용됩니다. 메인 서버 메인 서버가 명령을 보내고 응답을 받습니다
구독 연결: 메인 서버의 --sentinel-:hello 채널

Redis의 Sentinel 모드를 분석하고 구축 및 실행 프로세스에 대해 이야기합니다.

을 구독하는 데 사용됩니다. 2. 메인 마스터 정보를 가져옵니다.

Sentinel의 기본값은 10초입니다. 일단 모니터링되는 마스터 서버에 info 명령을 보내 마스터 서버와 그 하위 슬레이브 서버에 대한 정보를 얻습니다.

Redis의 Sentinel 모드를 분석하고 구축 및 실행 프로세스에 대해 이야기합니다.

3. 슬레이브 슬레이브 정보 획득

Sentinel은 마스터 서버에 새로운 슬레이브 서버가 나타나는 것을 발견하면 슬레이브 서버에 대한 명령 연결 및 구독 연결도 설정합니다.

명령 연결이 설정된 후에도 Sentinel은 기본적으로 10초마다 한 번씩 슬레이브 서버에 info 명령을 보내고 슬레이브 서버의 정보를 기록합니다.

Redis의 Sentinel 모드를 분석하고 구축 및 실행 프로세스에 대해 이야기합니다.

4. 구독 방식으로 마스터 서버와 슬레이브 서버에 메시지 보내기

Sentinel은 기본적으로 모니터링되는 모든 마스터 서버와 슬레이브 서버에 2초마다 메시지를 보냅니다. : hello 채널을 통해 메시지를 보냅니다. 메시지에는 Sentinel 자체 정보와 메인 서버의 정보가 포함됩니다.

5. 마스터 서버와 슬레이브 서버로부터 채널 정보 수신

Sentinel이 마스터 서버 또는 슬레이브 서버와 구독 연결을 설정하면 Sentinel은 구독 연결을 통해 서버에 다음 명령을 보냅니다

在redis-sentinel1目录下 ./redis-sentinel sentinel.conf
在redis-sentinel2目录下 ./redis-sentinel sentinel.conf
在redis-sentinel3目录下 ./redis-sentinel sentinel.conf

로그인 후 복사

왜냐하면 Sentinel은 마스터 서버나 슬레이브 서버를 구독하여 새로운 Sentinel의 추가를 감지할 수 있기 때문입니다. 새로운 Sentinel이 합류하면 상호 인식되는 Sentinel은 명령 연결을 통해 통신할 수 있습니다. Sentinel彼此之间只创建命令连接，而不创建订阅连接

6. 주관적인 오프라인 상태 감지

Sentinel은 명령 연결을 설정한 모든 인스턴스(마스터 서버, 슬레이브 서버 및 기타 Sentinel)에 초당 한 번씩 PING 명령을 보냅니다. 밀리초 밀리초 다운 후 밀리초 내에 잘못된 응답이 반환되고(+PONG, -LOADING 및 -MASTERDOWN 제외) 인스턴스가 응답하지 않는 경우(시간 초과) Sentinel은 인스턴스를 주관적으로 오프라인(SDown)으로 간주합니다.

7. 객관적으로 오프라인 상태를 확인하세요

Sentinel이 메인 서버가 주관적으로 오프라인이라고 판단하면

Sentinel은 이 메인 서버를 동시에 모니터링하는 다른 모든 Sentinel에 쿼리 명령을 보냅니다

호스트의

subscribe—sentinel—:hello

로그인 후 복사

다른 센티넬 답글

<down_state> <leader_runid> <leader_epoch>

로그인 후 복사

判断它们是否也认为主服务器下线。如果达到Sentinel配置中的quorum数量的Sentinel实例都判断主服务器为主观下线，则该主服务器就会被判定为客观下线(ODown)。

8、选举Leader Sentinel

当一个主服务器被判定为客观下线后，监视这个主服务器的所有Sentinel会通过选举算法（raft），选出一个Leader Sentinel去执行failover（故障转移）操作。

哨兵选举

Raft

Raft协议是用来解决分布式系统一致性问题的协议。

Raft协议描述的节点共有三种状态：Leader, Follower, Candidate。

term：Raft协议将时间切分为一个个的Term（任期），可以认为是一种“逻辑时间”。

选举流程

Raft采用心跳机制触发Leader选举

系统启动后，全部节点初始化为Follower，term为0。
节点如果收到了RequestVote或者AppendEntries，就会保持自己的Follower身份
节点如果一段时间内没收到AppendEntries消息，在该节点的超时时间内还没发现Leader，Follower就会转换成Candidate，自己开始竞选Leader。
- 一旦转化为Candidate，该节点立即开始下面几件事情：
  - 增加自己的term。
  - 启动一个新的定时器。
  - 给自己投一票。
  - 向所有其他节点发送RequestVote，并等待其他节点的回复。
如果在计时器超时前，节点收到多数节点的同意投票，就转换成Leader。同时向所有其他节点发送AppendEntries，告知自己成为了Leader。
每个节点在一个term内只能投一票，采取先到先得的策略，Candidate前面说到已经投给了自己，Follower会投给第一个收到RequestVote的节点。
Raft协议的定时器采取随机超时时间，这是选举Leader的关键。
在同一个term内，先转为Candidate的节点会先发起投票，从而获得多数票。

Sentinel的leader选举流程

1、某Sentinel认定master客观下线后，该Sentinel会先看看自己有没有投过票，如果自己已经投过票给其他Sentinel了，在一定时间内自己就不会成为Leader。
2、如果该Sentinel还没投过票，那么它就成为Candidate。
3、Sentinel需要完成几件事情：
- 更新故障转移状态为start
- 当前epoch加1，相当于进入一个新term，在Sentinel中epoch就是Raft协议中的term。
- 向其他节点发送is-master-down-by-addr命令请求投票。命令会带上自己的epoch。
- 给自己投一票（leader、leader_epoch）
4、当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；（通过判断epoch）
5、Candidate会不断的统计自己的票数，直到他发现认同他成为Leader的票数超过一半而且超过它配置的quorum，这时它就成为了Leader。
6、其他Sentinel等待Leader从slave选出master后，检测到新的master正常工作后，就会去掉客观下线的标识。

故障转移

当选举出Leader Sentinel后，Leader Sentinel会对下线的主服务器执行故障转移操作

1.它会将失效Master的其中一个Slave升级为新的Master,并让失效Master的其他Slave改为复制新的Master；
2.当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。
3.Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行replicaof的配置，sentinel.conf的监控目标会随之调换。

主服务器的选择