Redis의 고가용성 및 높은 동시성 메커니즘에 대한 자세한 설명

1. 높은 동시성 메커니즘

우리는 Redis가 단일 스레드를 기반으로 하고 독립형 모드에서는 수만 개만 전달할 수 있다는 것을 알고 있으므로 아래에서 수십만 개의 용량을 향상시키는 방법은 무엇입니까? 빅 데이터 Redis의 마스터-슬레이브 아키텍처와 읽기 및 쓰기 분리를 통해 높은 동시 요청을 달성합니다.

동영상 강좌 추천 →: "수백만 개의 데이터 동시성 솔루션(이론 + 실무)"

1. 마스터-슬레이브 복제

redis 마스터-슬레이브 복제 구성은 강조되지 않고 주로 다릅니다. 마스터-슬레이브 구성 복제 원리 및 프로세스: Redis의 마스터-슬레이브 복제 과정에서 여러 슬레이브 머신을 구축하려면 관리자로서 마스터 호스트가 필요합니다. 슬레이브 슬레이브가 시작을 시도하면 마스터 호스트로 PSYNC 명령을 보냅니다. 이때 슬레이브 슬레이브가 다시 연결되면 슬레이브 슬레이브가 가지고 있지 않은 데이터가 마스터 호스트에서 복사됩니다. 처음 연결하면 전체 재동기화가 시작됩니다. 트리거 후 마스터 호스트는 RDB 스냅샷 파일을 생성하기 위해 백그라운드에서 프로세스를 시작하고 동시에 이 기간의 쓰기 작업을 캐시에 저장합니다. RDB 파일이 생성되면 RDB 파일을 보냅니다. 그러면 슬레이브 머신은 파일을 먼저 디스크에 기록한 다음 메모리에 로드합니다. 마지막으로 마스터 호스트도 메모리에 캐시된 데이터를 슬레이브 머신으로 보냅니다. 동시. 마스터-슬레이브 네트워크 장애가 발생하고 여러 슬레이브가 다시 연결되면 마스터는 모든 슬레이브를 서비스하기 위해 하나의 RDB만 다시 시작합니다. [관련 권장 사항: Redis 동영상 튜토리얼]

Breakpoint 이력서: 마스터와 슬레이브에 복제본 오프셋이 있으며, 그 안에 마스터 ID가 있습니다. 네트워크 오류가 발생하면 해당하는 마지막 복제본 오프셋을 찾아 복사합니다. 해당 오프셋을 찾을 수 없으면 전체 재동기화가 트리거됩니다.

①복제 완료

(1) 슬레이브 노드가 시작되고 마스터 노드의 호스트와 IP를 포함하여 마스터 노드의 정보만 저장되지만 복제가 시작되지 않았습니다

어디에서 진행하나요? 마스터 호스트 및 IP는 redis에서 나옵니다. conf의 슬레이브 구성

(2) 슬레이브 노드 내부에는 연결하고 복사할 새 마스터 노드가 있는지 매초 확인하는 예약된 작업이 있습니다. 마스터 노드와 소켓 네트워크 연결
(3) 슬레이브 노드 마스터 노드에 ping 명령 보내기
(4) 비밀번호 인증, 마스터가 requirepass를 설정하면 슬레이브 노드는 인증을 위해 masterauth 비밀번호를 보내야 합니다
(5) 마스터 노드는 처음으로 전체 복제를 수행하고 모든 데이터를 슬레이브 노드로 보냅니다
(6) 마스터 노드는 계속해서 명령을 작성하고 이를 슬레이브 노드에 비동기적으로 복사합니다

②데이터 동기화와 관련된 핵심 메커니즘

은 다음을 의미합니다. 슬레이브가 처음으로 msater에 연결될 때 수행되는 전체 복사. 그 과정에서 일부 세부 메커니즘

(1) 마스터와 슬레이브 모두 오프셋을 유지합니다.

마스터는 지속적으로 자체적으로 오프셋을 축적하고 슬레이브는 또한 슬레이브는 매초 자체 오프셋을 마스터에 보고하고 마스터도 각 슬레이브의 오프셋을 저장합니다.

이는 전체 복제에 특별히 사용된다는 의미는 아닙니다. 즉, 마스터와 슬레이브 모두 서로의 데이터 불일치를 알기 위해서는 자신의 데이터 오프셋을 알아야 한다는 것입니다

(2) 백로그

마스터 노드에는 백로그가 있으며 기본 크기는 1MB입니다

마스터 노드가 슬레이브 노드에 데이터를 복사할 때 백로그에도 동기적으로 데이터 복사본을 작성합니다
백로그는 주로 전체 복제가 중단될 때 증분 복사에 사용됩니다

(3) 마스터 실행 ID

info 서버 , 마스터 실행 ID를 볼 수 있습니다

호스트+IP를 기반으로 마스터 노드를 찾으면 신뢰할 수 없습니다. 마스터 노드가 다시 시작되거나 데이터가 변경되면 슬레이브 노드는 다른 실행 ID를 기반으로 해야 합니다. 실행 ID가 다르면 전체 복사본을 만드세요
실행 ID를 변경하지 않고 Redis를 다시 시작해야 하는 경우 redis-cli debug reload 명령을 사용할 수 있습니다

(4) pync

슬레이브 노드에서 pync를 사용하여 복사 마스터 노드, pync runid 오프셋

마스터 노드는 자체 상황에 따라 응답 정보를 반환합니다. 전체 복사를 트리거하는 FULLRESYNC runid 오프셋이거나 증분 복사를 트리거하는 CONTINUE일 수 있습니다

3전체 복사

(1) 마스터는 bgsave를 실행하고 로컬에서 rdb 스냅샷 파일을 생성합니다
(2) 마스터 노드는 rdb 스냅샷 파일을 슬레이브 노드로 보냅니다. rdb 복사 시간이 60초(repl-timeout)를 초과하면 슬레이브 노드는 복사가 실패하면 이 매개변수를 적절하게 조정하면 된다고 생각할 것입니다
(3) 기가비트 네트워크 카드가 있는 시스템의 경우 일반적으로 100MB, 6G 파일이 초당 전송되며 이는 60초를 초과할 가능성이 높습니다
(4) 마스터 노드가 RDB를 생성할 때 , 모든 새로운 쓰기는 메모리에 캐시됩니다. salve 노드가 rdb를 저장한 후 새 쓰기 명령이 salve 노드에 복사됩니다
(5) client-output-buffer-limit 슬레이브 256MB 64MB 60. 복사하는 동안 버퍼가 계속 소모됩니다. 64MB를 초과하거나 한 번에 256MB를 초과하면 복사를 중지하고 복사가 실패합니다
(6) 슬레이브 노드는 rdb를 수신한 후 이전 데이터를 지우고 rdb를 다시 로드합니다. Service
(7) 슬레이브 노드에 AOF가 활성화되어 있으면 BGREWRITEAOF가 즉시 실행되어 AOF

rdb 생성을 다시 작성하고, rdb는 네트워크를 통해 복사됩니다. , 슬레이브 오래된 데이터 정리, 슬레이브 다시 쓰기 시간이 많이 걸립니다

복사된 데이터의 양이 4G~6G 사이라면 전체 복사 시간은 1분 30초에서 2분 정도 걸릴 것 같습니다

4증분 복사

(1) 전체 복사 과정에서 마스터-슬레이브 네트워크 연결이 끊어지면 슬레이브가 다시 시작됩니다. 마스터에 연결하면 증분 복제가 시작됩니다
(2) 마스터는 손실된 데이터의 일부를 마스터에서 직접 얻습니다. 기본 백로그는 1MB입니다. (3) msater는 슬레이브가 보낸 psync의 오프셋을 기반으로 합니다.

⑤heartbeat

마스터 및 슬레이브 노드는 백로그에서 데이터를 얻습니다. 서로 하트비트 정보를 보냅니다

master는 기본적으로 10초마다 하트비트를 보내고, salve 노드는 1초마다 하트비트를 보냅니다

⑥비동기 복제

master가 매번 쓰기 명령을 받은 후 데이터가 내부적으로 기록됩니다. 그런 다음 슬레이브 노드에 비동기적으로 전송됩니다

2. 읽기 및 쓰기 분리: 마스터는 쓰기 작업을 담당하고 슬레이브는 마스터가 액세스 쿼리의 양을 줄이는 데 도움을 줍니다

2.

동시성이 높은 경우 마스터가 하나인 여러 클러스터와 백업이 여러 개 있으면 동시성 문제를 해결할 수 있지만, 마스터가 하나만 다운되면 전체 시스템이 쓰기 작업을 수행할 수 없고 슬레이브도 수행할 수 없습니다. 데이터를 동기화할 수 없으며 전체 시스템이 마비되어 전체 시스템을 사용할 수 없습니다. Redis의 고가용성 메커니즘은 Sentinel 메커니즘입니다. Sentinel은 Redis 클러스터의 중요한 구성 요소이며 클러스터 모니터링, 정보 알림, 장애 조치 및 구성 센터를 담당합니다.

(1) Redis 마스터 및 슬레이브 프로세스가 정상적으로 작동하는지 모니터링하는 클러스터 모니터링

(2) 메시지 알림, Redis 인스턴스가 실패하면 센티널은 관리자에게 경보 알림 메시지를 보내는 역할
(3 ) Failover , 마스터 노드가 끊기면 자동으로 슬레이브 노드로 이동
(4) Configuration Center, Failover 발생 시 클라이언트에 새로운 마스터 주소를 통보
Sentinel 자체가 분산되어 클러스터로 작동하며, 서로 협력해야 합니다.

마스터 노드가 다운된 것으로 확인되면 다수의 센티넬의 동의가 필요합니다. 여기에는 분산 선거가 포함됩니다.

센티넬 메커니즘은 견고성을 보장하기 위해 최소 3개의 노드를 보장해야 합니다. 테스트 중에 두 개의 노드(하나는 마스터 노드이고 다른 하나는 슬레이브 노드)만 제공하면 이 두 노드에 센티넬이 있게 됩니다. 모니터링을 담당합니다. 마스터 호스트 중 하나가 다운되면 센티널이 선택을 수행해야 합니다. 그러면 마스터 노드의 s1 센티널은 더 이상 작동할 수 없으며 마스터 노드의 s2 센티널만 선택을 수행할 수 있습니다. 그런 다음 선택 후 장애 조치를 위해 센티널이 필요합니다. 작업을 수행하려면 대다수 매개변수는 장애 조치에 필요한 센티널 수를 지정합니다. 이때 장애 조치를 위한 S2 센티널은 하나만 있습니다. 따라서 견고성을 보장하려면 최소 3개의 노드가 필요합니다.

3. 고가용성 및 높은 동시성으로 인해 발생하는 데이터 손실 문제

(1) 비동기 복제로 인한 데이터 손실

마스터 -> 슬레이브 복제가 비동기식이므로 아직 일부 데이터가 복제되지 않을 수 있습니다. 마스터가 다운되고 데이터의 이러한 부분이 손실됩니다.

(2) 스플릿 브레인으로 인한 데이터 손실

스플릿 브레인, 즉 마스터가 위치한 머신이 갑자기 일반 네트워크를 벗어나 다른 슬레이브 머신과 연결할 수 없지만 실제로는 마스터가 여전히 실행 중이고,

이때 Sentinel은 마스터가 다운되었다고 생각하고 선거를 시작하여 다른 슬레이브를 마스터로 전환할 수 있습니다.

이때 클러스터에는 소위 2개의 마스터가 있게 됩니다.

이때 특정 A 슬레이브가 마스터로 전환되었지만 클라이언트가 새 마스터로 전환할 시간이 없을 수 있으며 이전 마스터에 계속 쓰는 데이터가 손실될 수 있습니다.

따라서 기존 마스터가 다시 복원되면 슬레이브로 정지되며, 새로운 마스터가 등장하면 자체 데이터가 지워지고 새 마스터에서 데이터가 다시 복사됩니다.

비동기 복제 및 브레인 분할로 인한 데이터 손실 해결

min-slaves-to-write 1
 min-slaves-max-lag 10

슬레이브가 1개 이상 필요, 데이터 복제 및 동기화 지연은 10초를 초과할 수 없음

슬레이브를 모두 사용할 경우 데이터 복제 및 동기화 지연이 10초를 초과할 수 있음 , 그러면 이 시점에서 마스터는 더 이상 어떤 요청도 받지 않습니다

위의 두 가지 구성을 사용하면 비동기 복제 및 분할 브레인으로 인한 데이터 손실을 줄일 수 있습니다.

(1) 비동기 복제로 인한 데이터 손실을 줄입니다.

min-slaves-max-lag 구성을 사용하면 슬레이브가 복제한 후 ACK 지연이 너무 길면 마스터가 다운된 후 너무 많은 데이터가 손실되었을 수 있다고 간주하여 쓰기 요청을 거부합니다. 이렇게 하면 일부 데이터가 슬레이브에 동기화되지 않아 발생하는 데이터 손실을 줄일 수 있습니다. 마스터가 다운되면 제어 가능한 범위 내에서 내부

(2) 분할 브레인 데이터 손실을 줄입니다

마스터에 분할 브레인이 있고 다른 슬레이브와의 연결이 끊어지면 위의 두 구성을 통해 다음을 보장할 수 있습니다. 지정된 수의 슬레이브에게 계속 데이터를 보낼 수 없으며, 슬레이브가 10초 이상 자신에게 ack 메시지를 보내지 않으면 클라이언트의 쓰기 요청을 직접 거부합니다

이런 식으로 브레인 분할 후 올드 마스터는 클라이언트의 새 데이터를 수락하지 않으므로 데이터 손실을 방지할 수 있습니다.

위 구성을 사용하면 슬레이브와의 연결이 끊어지고 10초 후에 어떤 슬레이브도 ack를 제공하지 않으면 새 쓰기 요청을 거부하게 됩니다

따라서 분할 두뇌 시나리오에서는 최대 10초의 데이터가 손실됩니다

더 많은 프로그래밍 관련 지식을 보려면 프로그래밍 소개를 방문하세요! !

위 내용은 Redis의 고가용성 및 높은 동시성 메커니즘에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!