Redis 고가용성을 위한 두 가지 구현 솔루션은 무엇입니까?

Redis에서 고가용성(HA)을 달성하기 위해 다음 두 가지 방법이 사용됩니다.

• 마스터-슬레이브 데이터 복제.

• 센티넬을 사용하여 데이터 노드의 작동을 모니터링합니다. 마스터 노드에 문제가 발생하면 슬레이브 노드의 최상위부터 서비스가 계속됩니다.

마스터-슬레이브 복제

Redis에서는 마스터-슬레이브 노드가 복제하는 데이터를 전체 복제와 부분 복제로 나눌 수 있습니다.

이전 버전에서 전체 복사 기능 구현

전체 복사는 snyc 명령을 사용하여 구현됩니다. 프로세스는 다음과 같습니다.

• 서버에서 메인 서버로 동기화 명령을 보냅니다.

• sync 명령을 받은 후 메인 서버는 bgsave 명령을 호출하여 ***rdb 파일을 생성하고 이 파일을 슬레이브 서버에 동기화합니다. 이런 식으로 슬레이브 서버가 rdb 파일을 로드한 후 상태가 표시됩니다. 명령을 내릴 때 마스터 서버 bgsave 일관성을 사용하여 실행됩니다.

• 마스터 서버는 명령 버퍼에 저장된 쓰기 명령을 슬레이브 서버에 동기화하고, 슬레이브 서버는 이러한 명령을 실행하여 슬레이브 서버의 상태가 마스터 서버의 현재 상태와 일치하도록 합니다.

이전 버전의 전체 복사 기능의 주요 문제점은 슬레이브 서버의 연결이 끊어졌다가 다시 연결될 때 슬레이브 서버에 이미 일부 데이터가 있더라도 전체 복사를 수행해야 한다는 점입니다. 이는 매우 비효율적입니다. , 그래서 Redis의 새 버전에서는 이 부분이 개선되었습니다.

새 버전에서 전체 복사 기능 구현

최신 버전의 Redis는 psync 명령을 사용하여 sync 명령을 대체합니다. psync 명령은 전체 동기화뿐만 아니라 부분 동기화도 달성할 수 있습니다.

복사 오프셋

복제를 수행하는 두 당사자인 마스터 서버와 슬레이브 서버는 각각 복제 오프셋을 유지합니다.

• 마스터 서버가 N바이트의 데이터를 슬레이브 서버에 동기화할 때마다 수정됩니다. 그 자체 복사 오프셋 + N.

• 슬레이브 서버가 마스터 서버에서 N바이트의 데이터를 동기화할 때마다 자체 복제 오프셋 +N을 수정합니다.

백로그 버퍼 복사

메인 서버는 내부적으로 고정 길이의 선입선출 대기열을 복제 백로그 버퍼로 유지하며 기본 크기는 1MB입니다.

마스터 서버가 명령 전파를 수행하면 쓰기 명령을 슬레이브 서버에 동기화할 뿐만 아니라 복제 백로그 버퍼에 쓰기 명령도 씁니다.

서버 실행 ID

각 Redis 서버에는 실행 ID가 있습니다. 실행 ID는 서버가 시작될 때 서버에서 자동으로 생성되며, 마스터 서버는 자체 실행 ID를 슬레이브 서버에 보냅니다. 마스터 서버의 실행 ID가 저장됩니다.

슬레이브 서버 Redis가 연결 해제되었다가 재접속된 후 동기화 시 실행 중인 ID를 기준으로 동기화 진행 여부를 판단합니다.

• 슬레이브 서버에 저장된 메인 서버 실행 ID와 현재 메인 서버 실행 ID가 일치할 경우, 이번에 간주되어 연결이 끊어졌다가 다시 연결된 메인 서버는 이전에 복제된 메인 서버이며, 메인 서버는 계속해서 부분 동기화 작업을 시도할 수 있습니다.

• 그렇지 않고, 메인 서버 실행 ID가 전후로 다를 경우 전체 동기화 과정이 완료된 것으로 간주됩니다.

psync 명령 프로세스

이전 준비를 통해 psync 명령 프로세스 분석을 시작하겠습니다.

• 슬레이브 서버가 이전에 마스터 서버를 복사하지 않았거나 이전에 아무 명령도 실행되지 않은 슬레이브 서버인 경우 , 그러면 슬레이브 서버는 psync ? -1 명령을 마스터 서버에 보내 마스터 서버에 모든 데이터를 동기화하도록 요청합니다.

• 그렇지 않고 슬레이브 서버가 이미 일부 데이터를 동기화한 경우 슬레이브 서버는 pync offset> 명령을 마스터 서버로 보냅니다. 여기서 runid는 마스터 서버의 마지막 실행 ID입니다. offset은 현재 슬레이브 서버입니다.

마스터 서버가 처음 두 경우에 psync 명령을 수신한 후 다음 세 가지 가능성이 발생합니다.

• 마스터 서버는 마스터 서버가 서버는 슬레이브 서버와의 통신이 필요합니다. 데이터 동기화 작업을 완료하세요. 현재 메인 서버의 실행 아이디는 runid 이고, 복제 오프셋은 offset 입니다.

• 메인 서버가 +continue로 응답하면 메인 서버와 슬레이브 서버가 부분 데이터 동기화 작업을 수행하고, 슬레이브 서버에서 누락된 데이터를 동기화할 수 있다는 의미입니다.

• 마스터 서버가 -err로 응답하면 마스터 서버 버전이 2.8 미만이고 psync 명령을 인식할 수 없다는 의미입니다. 이때 슬레이브 서버는 동기화 명령을 마스터 서버에 보내 완료를 수행합니다. 전체 데이터 동기화.

센티넬 메커니즘 개요

Redis는 센티넬 메커니즘을 사용하여 고가용성(HA)을 달성합니다. 대략적인 작동 원리는 다음과 같습니다.

• Redis는 센티넬 노드 세트를 사용하여 마스터의 가용성을 모니터링합니다. -슬레이브 Redis 서비스.

• Redis 마스터 노드에 장애가 발생한 것이 발견되면 센티넬 노드가 리더로 선출됩니다.

• Sentinel***은 나머지 슬레이브 Redis 노드에서 Redis 노드를 새로운 기본 Redis 노드로 선택하여 외부 서비스를 제공합니다.

위에서는 Redis 노드를 두 가지 범주로 나눕니다.

• 센티넬 노드(sentinel): 노드의 동작을 모니터링하는 역할을 담당합니다.

• 데이터 노드: 일반적으로 클라이언트 요청을 처리하는 Redis 노드로, 마스터와 슬레이브로 구분됩니다.

위는 일반적인 프로세스입니다. 이 프로세스에서는 다음 문제를 해결해야 합니다.

• Redis 데이터 노드를 모니터링하는 방법은 무엇입니까?

• Redis 데이터 노드가 유효하지 않은지 어떻게 확인하나요?

• 센티넬 *** 노드를 선택하는 방법은 무엇입니까?

• Sentinel 노드가 새로운 기본 Redis 노드를 선택하는 기준은 무엇인가요?

이 질문에 하나씩 답해 보겠습니다.

세 가지 모니터링 작업

센티넬 노드는 세 가지 예약된 모니터링 작업을 통해 Redis 데이터 노드의 서비스 가용성을 모니터링합니다.

info 명령

10초마다 각 센티널 노드는 마스터 및 슬레이브 Redis 데이터 노드에 info 명령을 보내 새로운 토폴로지 정보를 얻습니다.

Redis 토폴로지 정보에는 다음이 포함됩니다.

• 이 노드의 역할: 마스터 또는 슬레이브.

• 마스터 및 슬레이브 노드의 주소 및 포트 정보입니다.

이런 방식으로 센티넬 노드는 info 명령으로부터 슬레이브 노드 정보를 자동으로 얻을 수 있으므로, 나중에 추가되는 슬레이브 노드 정보는 명시적인 구성 없이 자동으로 감지될 수 있습니다.

정보를 __sentinel__:hello 채널에 동기화

2초마다 각 Sentinel 노드는 자체 마스터 노드 정보와 현재 Sentinel 노드 정보를 Redis 데이터 노드의 __sentinel__:hello 채널에 동기화합니다. 왜냐하면 다른 Sentinel 노드도 구독하기 때문입니다. 따라서 이 작업은 실제로 센티넬 노드 간에 마스터 노드와 센티넬 노드에 대한 정보를 교환합니다.

이 작업은 실제로 다음 두 가지를 수행합니다. * 새로운 Sentinel 노드 발견: 새로운 Sentinel 노드가 합류하면 이때 새로운 Sentinel 노드의 정보가 저장되며 이후 Sentinel 노드와 연결이 설정됩니다. 다음과 같은 방법으로 다시 작성하세요. * 추후 마스터 노드의 오프라인 여부를 객관적으로 판단할 수 있도록 마스터 노드의 상태 정보를 교환합니다.

데이터 노드에서 하트비트 감지 수행

1초마다 각 센티널 노드는 하트비트 감지를 위해 마스터, 슬레이브 데이터 노드 및 기타 센티널 노드에 ping 명령을 보냅니다. 이 하트비트 감지는 데이터 노드가 후속적으로 주관적으로 판단하는 것입니다. 에 따라 오프라인 상태입니다.

주관적 오프라인과 객관적인 오프라인

주관적 오프라인

위의 세 가지 모니터링 작업 중 세 번째 감지 하트비트 작업은 구성된 다운 후 밀리초 이후에도 유효한 응답을 받지 못하면 데이터 노드를 고려합니다. "주관적으로 오프라인(sdown)"입니다.

왜 "주관적 오프라인"이라고 하나요? 분산 시스템에서는 여러 머신이 함께 작동하기 때문에 네트워크에서 다양한 상황이 발생할 수 있다. 한 노드만으로는 데이터 노드가 오프라인이라고 판단하기에는 충분하지 않다." .

Objective Offline

센티넬 노드가 마스터 노드가 주관적으로 오프라인이라고 생각하는 경우, 센티넬 노드는 "sentinel is-master-down-by addr" 명령을 사용하여 마스터 노드가 오프라인 상태인지 여부를 다른 센티넬 노드에 문의해야 합니다. 오프라인, 센티넬 노드의 절반 이상이 오프라인이라고 응답하면 이때 마스터 노드는 "객관적으로 오프라인"인 것으로 간주됩니다.

센티넬 선출***

마스터 노드가 객관적으로 오프라인 상태가 되면 센티넬 노드를 센티넬***로 선출하여 새 마스터 노드를 선택하는 후속 작업을 완료해야 합니다.

이번 선거의 일반적인 아이디어는 다음과 같습니다.

• 각 센티널 노드는 "sentinel is-master-down-by addr" 명령을 다른 센티넬 노드에 전송하여 센티널***이 되기 위해 신청합니다.

• 각 센티넬 노드가 "sentinel is-master-down-by addr" 명령을 받으면 *** 노드에 대해서만 투표가 허용되며 다른 노드의 명령은 거부됩니다.

• 센티넬 노드가 승인 표의 절반 이상을 받으면 센티넬이 됩니다***.

• 처음 3단계에서 일정 시간 내에 파수꾼***이 선택되지 않으면 다음 선거가 다시 시작됩니다.

***를 선출하는 과정은 뗏목에서 리더를 선출하는 과정과 매우 유사하다는 것을 알 수 있습니다.

새 마스터 노드 선택

나머지 Redis 슬레이브 노드 중에서 다음 순서로 새 마스터 노드를 선택합니다.

• 주관적인 오프라인, 연결 끊김 등 "불건전한" 데이터 노드를 필터링합니다. line, sentinel node ping 명령에 5초 이내에 응답하지 않은 노드, 마스터 노드와 연결이 끊어진 슬레이브 노드.

• 슬레이브 우선순위 ***가 있는 슬레이브 노드가 있으면 해당 노드를 반환하고, 그렇지 않으면 후속 프로세스를 계속 실행합니다.

• 복사 오프셋 ***이 있는 슬레이브 노드를 선택합니다. 이는 이 슬레이브 노드의 데이터가 가장 완전하다는 것을 의미하며, 존재하지 않으면 반환되고 후속 프로세스를 계속합니다.

• 이 시점에서 나머지 슬레이브 노드의 상태는 모두 동일하므로, 가장 작은 runid를 가진 슬레이브 노드를 선택하세요.

새 마스터 노드 승격

새 마스터 노드를 선택한 후 해당 노드를 새 마스터 노드로 만들려면 *** 프로세스가 필요합니다.

• Sentinel***은 이전 단계에서 선택한 슬레이브 노드에 "slaveof no one" 명령을 실행하여 이 노드를 마스터 노드로 만듭니다.

• Sentinel***은 나머지 슬레이브 노드에 명령을 보내 새 마스터 노드의 슬레이브 노드로 만듭니다.

• 센티넬 노드 세트는 원래 마스터 노드를 슬레이브 노드로 업데이트하고, 복구되면 새 마스터 노드의 데이터를 복사하라는 명령을 받습니다.

위 내용은 Redis 고가용성을 위한 두 가지 구현 솔루션은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!