Redis 센티널 메커니즘의 원리 소개(그림 및 텍스트)

이 글의 내용은 Redis의 Sentinel 메커니즘을 소개하여 누구나 Sentinel 메커니즘의 원리와 구현 방법을 이해할 수 있도록 하는 것입니다. 도움이 필요한 친구들이 참고할 수 있기를 바랍니다.

Overview

Redis 복제에는 단점: 호스트 마스터가 다운되면 아무도 슬레이브를 사용하지 않는 등 스위치를 수동으로 해결해야 합니다. 실제로 마스터-슬레이브 복제는 구현되지 않았습니다. 고가용성은 백업 머신에 중점을 두고 클러스터 내 시스템의 중복성을 사용합니다. 시스템의 머신이 손상되면 다른 백업 머신이 이를 대신하여 서비스를 시작할 수 있습니다. .

마스터-슬레이브 복제 문제

#🎜🎜 #Once 마스터 노드가 다운되어 쓰기 서비스를 사용할 수 없는 경우 수동으로 전환하여 마스터 노드를 다시 선택하고 마스터-슬레이브 관계를 수동으로 설정해야 합니다.

그럼 어떻게 해결해야 할까요? 각 기계의 상태를 모니터링하고 적시에 조정할 수 있는 모니터링 프로그램이 있으면 수동 작업을 자동 작업으로 전환할 수 있습니다. 센티넬의 등장은 이 문제를 해결하기 위한 것이다.

센티넬 메커니즘의 원리와 구현

Redis Sentinel #🎜 🎜#Redis Sentinel은 여러 Sentinel 노드와 Redis 데이터 노드를 포함하는 분산 아키텍처입니다. 각 Sentinel 노드는 노드가 있을 때 데이터 노드와 다른 Sentinel 노드를 모니터링합니다. 연결할 수 없는 것으로 확인되면 해당 노드는 오프라인으로 표시됩니다. 식별된 마스터 노드가 마스터 노드인 경우 다른 Sentinel 노드와도 "협상"합니다. 대부분의 Sentinel 노드가 마스터 노드에 연결할 수 없다고 판단하면 Sentinel 노드를 선택하여 자동 장애 조치를 완료하고 동시에 해당 노드에 알립니다. Redis 애플리케이션 측면에서는 이러한 변화가 실시간으로 이루어집니다. 전체 프로세스가 완전히 자동으로 이루어지며 수동 개입이 필요하지 않으므로 이 솔루션은 Redis의 고가용성 문제를 효과적으로 해결합니다.

그림과 같이:

기본 장애 조치 프로세스 # 🎜🎜#1) 이때 두 개의 슬레이브 노드가 마스터 노드와의 연결이 끊어지고 마스터-슬레이브 복제가 실패합니다.

2) 각 Sentinel 노드는 정기적인 모니터링을 통해 마스터 노드의 장애를 발견합니다

#🎜🎜 #

3) 여러 Sentinel 노드가 마스터 노드의 장애에 동의하면 노드 중 하나가 장애 조치를 담당하는 리더로 선출됩니다.

4) 전체 프로세스는 기본적으로 수동 조정과 동일하지만 자동으로 완료됩니다.

5) 장애 조치 후 전체 Redis Sentinel 구조가 새 마스터 노드를 다시 선택했습니다.

Example

Docker를 사용하여 다음 redis 컨테이너###

redis-sentinel1    172.10.0.9    22530 -> 22530    sentinel
redis-sentinel2    172.10.0.10    22531 -> 6379    sentinel
redis-sentinel3    172.10.0.11    22532 -> 6379    sentinel
redis-master2    172.10.0.5    6383  -> 6379    Master
redis-slave2    172.10.0.6    6384  -> 6379    Slave
redis-slave3    172.10.0.7    6385  -> 6379    Slave

#🎜🎜 ## ## ######구성#🎜🎜 ## ## ####Sentinel의 핵심 구성###

sentinel monitor mymaster 127.0.0.1 7000 2

모니터링 마스터 노드의 이름, IP, 포트는 여러 개의 Sentinel이 문제를 발견하여 장애 조치가 발생한다는 의미입니다. 예를 들어 2로 구성되면 최소 2개의 Sentinel 노드가 마스터 노드라고 생각한다는 의미입니다. 불가능하므로 판단은 객관적이어야 합니다. 설정이 작을수록 오프라인 레벨 도달 조건이 느슨해지며, 그 반대의 경우도 마찬가지입니다. 일반적으로 Sentinel 노드의 절반에 1을 더한 값으로 설정하는 것이 좋습니다.

sentinel down-after-millseconds mymaster 30000

타임아웃(밀리초 단위)입니다. 예를 들어, 컴퓨터에 ping을 실행했는데 오랜 시간이 지난 후에도 여전히 ping을 수행할 수 없다면 이는 문제가 있는 것으로 간주됩니다.

sentinel parallel-syncs mymaster 1

当 Sentinel 节点集合对主节点故障判定达成一致时，Sentinel 领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs 就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数，指出 Sentinel 属于并发还是串行。1代表每次只能复制一个，可以减轻 Master 的压力。

sentinel auth-pass <master-name> <password></password></master-name>

如果 Sentinel 监控的主节点配置了密码，sentinel auth-pass 配置通过添加主节点的密码，防止 Sentinel 节点对主节点无法监控。

sentinel failover-timeout mymaster 180000

表示故障转移的时间。

技巧

1）Sentinel 节点不应该部署在一台物理“机器”上。

这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比较流行的容器，它们虽然有不同的 IP 地址，但实际上它们都是同一台物理机，同一台物理机意味着如果这台机器有什么硬件故障，所有的虚拟机都会受到影响，为了实现 Sentinel 节点集合真正的高可用，请勿将 Sentinel 节点部署在同一台物理机器上。

2）部署至少三个且奇数个的 Sentinel 节点。

3个以上是通过增加 Sentinel 节点的个数提高对于故障判定的准确性，因为领导者选举需要至少一半加1个节点，奇数个节点可以在满足该条件的基础上节省一个节点。

【相关文章】

Redis主从复制的原理介绍（图文）

以上就是本篇文章的全部内容，希望能对大家的学习有所帮助。更多精彩内容大家可以关注php中文网相关教程栏目！！！

위 내용은 Redis 센티널 메커니즘의 원리 소개(그림 및 텍스트)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!