Redis 주종 동기 화

오늘 은 Redis 주종 동기 화 에 관 한 내용 을 공유 하고 싶 습 니 다.
레 디 스 서버 가 여러 대 있 을 때 메 인 서버 와 여러 대가 서버 에서 있 을 것 이라는 것 을 잘 알 고 있 습 니 다.일반적으로 메 인 서버 는 쓰기 작업 을 하고 서버 에서 읽 기 작업 을 한다.
그렇다면 서버 에서 메 인 서버 와 데 이 터 를 어떻게 동기 화 하 느 냐 는 문제 가 있다.
이 문 제 는 바로 오늘 의 내용 을 통 해 주종 동기 화 를 통 해 해결 한 것 이다.
글 의 내용 은 여전히 비교적 건조 하 므 로 모두 가 마음 을 가 라 앉 히 고 집중 해서 보 는 것 을 건의 합 니 다.글 의 끝 은 모두 에 게 간단 한 총 결 과 를 하고 요약 할 것 입 니 다.
1.주종 동기 화 방법
만약 에 현재 Redis 서버 가 2 대 있다 면 주 소 는 각각 127.0.0.1:6379 와 127.0.0.1:12345 입 니 다.
우 리 는 127.0.0.1:12345 의 클 라 이언 트 에 명령 을 입력 합 니 다.

127.0.0.1:12345> SLAVEOF 127.0.0.6379

이렇게 127.0.0.1:12345 서버 는 127.0.0.1:6379 의 데 이 터 를 복사 합 니 다.전 자 는 서버,후 자 는 서버 를 위주 로 하 는 것 이다.
위 와 같은 방식 으로 복사 하 는 것 외 에 설정 파일 의 slaveof 옵션 을 통 해 설정 할 수 있 습 니 다.
이 가능 하 다,~할 수 있다,...
ok,다음은 우리 가 계속 알 아 보 겠 습 니 다.
2.주종 동기 화 실현 과정
주종 동기 화 는 두 단계 로 나 뉜 다.동기 화 와 명령 전파 이다.

동기 화:서버 의 데이터베이스 상태 에서 주 서버 의 현재 데이터베이스 상태 로 업데이트 합 니 다.(데이터베이스 상 태 는 이 글 에서 처음에 무슨 뜻 인지 언급 되 었 습 니 다.잘 모 르 는 파트너 는 먼저 볼 수 있 습 니 다.

명령 전파:메 인 서버 데이터베이스 상태 가 수정 되면 메 인 서버 데이터베이스 상태 가 일치 하지 않 습 니 다.이 때 메 인 이 데이터 에서 일치 하 는 과정 으로 동기 화 되 어야 합 니 다.

위 는 동기 화 2 단계 의 역할 이 고 다음은 이 두 단계 의 실현 과정 을 조금 더 자세히 말씀 드 리 려 고 합 니 다.
여기 서 미리 설명해 야 한다.Redis 2.8 버 전에 서 주종 복 사 를 할 때 상기 두 가지 절 차 를 순서대로 실행 하고 2.8 부터 명령 만 수행 하면 전 파 될 수 있다.다음 글 에서 도 왜 이러 는 지 설명 할 까요?
2.1 동기 화
서버 에서 메 인 서비스 에 대한 동기 화 작업 은 sync 명령 을 통 해 이 루어 져 야 합 니 다.다음은 sync 명령 의 실행 절차 입 니 다.

서버 에서 메 인 서버 로 sync 명령 보 내기

sync 명령 을 받 은 후 메 인 서버 는 bgsave 명령 을 실행 하여 rdb 파일 을 만 들 고 버퍼 에 지금부터 실 행 된 쓰기 명령 을 기록 합 니 다.

bgsave 실행 완료 후 생 성 된 rdb 파일 을 서버 에서 보 내 서버 에서 데 이 터 를 업데이트 하 는 데 사용 합 니 다

메 인 서버 는 버퍼 에 기 록 된 쓰기 명령 을 서버 에 보 내 고 서버 에서 이 쓰기 명령 을 실행 한 후 데이터베이스 상태 가 메 인 서버 와 일치 합 니 다.

그림 으로 는 이렇다.

2.2 명령 전파
동기 화 작업 을 통 해 이때 주종 의 데이터베이스 상 태 는 사실 이미 일 치 했 지만 이런 일 치 된 상 태 는 고정불변 한 것 이 아니다.
동기 화 를 마 친 후 메 인 서버 에서 새로운 쓰기 명령 을 받 았 을 수도 있 습 니 다.이 명령 을 실행 한 후 메 인 데이터베이스 상태 가 일치 하지 않 습 니 다.
메 인 데이터베이스 상태 가 다시 일치 하도록 하기 위해 서 메 인 서버 는 서버 에서 명령 을 실행 하여 전파 작업 을 해 야 합 니 다.즉,방금 일치 하지 않 은 쓰기 명령 을 서버 에서 실행 하도록 보 내야 합 니 다.서버 실행 이 끝 난 후,주종 데이터베이스 상태 가 다시 일치 하 게 회복 되 었 다.
여기에 의문 하 나 를 삽입 방송 합 니 다.
위 와 같은 불일치 가 발생 한 후에 Redis 가 동기 화 작업 을 수행 하면 ok 이 아니 냐 는 독자 들 의 생각 이 있 는 지 모르겠다.
효과 적 으로 는 동기 화 를 회복 할 수 있 지만 필요 없다.동기 화 된 sync 명령 을 실현 하 는 것 은 자원 을 매우 소모 하 는 작업 이기 때문에 다음 그림 의 설명 을 보고 이해 할 것 이 라 고 믿 습 니 다.

동기 화 는 자원 을 매우 소모 하 는 작업 인 만큼 Redis 는 어떤 최적화 방법 이 있 습 니까?답 은 있 지.
2.3 최적화 판 동기 화 작업
위 에서 말 한 내용 을 기억 하 십 니까?2.8 버 전부터 주종 동기 화 는 명령 만 수행 하고 전파 하면 될 수 있 습 니 다.이것 도 sync 가 자원 을 비교적 소모 하기 때문에 채택 한 최적화 이다.
그럼 언제 이렇게 할 수 있 을까요?우 리 는 먼저 전제조건 을 살 펴 보 자.
주종 동기 화 실제 2 가지 상황:

첫 번 째 복사:서버 에서 현재 홈 서버 를 처음 복사 합 니 다(PS:홈 서버 가 바 뀔 수 있 습 니 다)

끊 긴 후 다시 복사:명령 전파 단계 에 있 는 메 인 서버 는 네트워크 문제 로 복 제 를 중단 하고 서버 에서 자동 으로 다시 연결 하여 메 인 서버 에 다시 연결 하고 계속 복사 합 니 다.

끊 긴 후 다시 복사 할 경우 2.8 버 전 이전에 동기 화(sync 명령)와 명령 전 파 를 다시 실행 합 니 다.
만약 에 끊 기 는 동안 메 인 서버(이미 만 키 쌍 이 있 음)는 몇 개의 쓰기 명령 만 실 행 했 을 뿐 서버 에서 이 몇 개의 명령 을 보완 하기 위해 sync 를 다시 실행 하여 새로운 rdb 파일 을 생 성 하 는 것 도 매우 비효 율 적 이다.
이 문 제 를 해결 하기 위해 2.8 은 sync 명령 대신 psync 명령 을 사용 하여 동기 화 작업 을 수행 합 니 다.
psync 는 전체 동기 화 와 부분 동기 화 두 가지 모드 를 가지 고 있 습 니 다.

완전 동기 화:첫 번 째 복사 상황 에 사용 되 며 실행 과정 은 sync 와 같 습 니 다.여기 서 더 이상 말 하지 않 습 니 다.

부분 재 동기 화:단선 후 재 복사 상황 에 사용 되 며,일정한 조건 을 만족 시 키 면 메 인 서버 는 단선 기간 에 실 행 된 쓰기 명령 을 서버 에 보 내 면 됩 니 다.

따라서 메 인 이 동기 화 에서 끊 긴 후에 다시 복사 하 는 경우 psync 의 일부 재 동기 화 모드 는 sync 의 비효 율 적 인 상황 을 해결 할 수 있 음 이 분명 하 다.
위의 소개 에서'일정한 조건 을 만족 시 키 자'는 것 이 나 타 났 는데 그것 은 또 무슨 조건 입 니까?사실은 편 이 량 의 비교 로 구체 적 으로 계속 아래 를 볼 수 있다.
2.4 부분 동기 화 실현
부분 중 동기 화 기능 은 다음 과 같은 세 부분 으로 구성 된다.

서버 로부터 의 복사 오프셋

메 인 서버 의 복사 압축 버퍼

서버 실행 id(run id)

2.4.1 복사 오프셋
복 사 를 실행 하 는 마스터 서버 는 각각 복사 오프셋 을 유지 합 니 다.

메 인 서버 는 서버 에서 n 개의 바이트 데 이 터 를 전파 할 때마다 자신의 복사 오프셋 을 n 으로 추가 합 니 다.

서버 에서 메 인 서버 에서 전 송 된 데 이 터 를 받 을 때 도 자신의 복사 오프셋 을 n

추가 합 니 다.
예 를 들 어:
현재 메 인 서버 의 복사 오프셋 이 10000 이면 서버 에서 30 개의 바이트 데 이 터 를 전파 하고 종료 후 복사 오프셋 은 10030 입 니 다.
이 때 서버 에서 30 개의 바이트 데 이 터 를 받 지 못 하고 끊 겼 습 니 다.다시 연결 한 후에 도 서버 에서 의 복사 오프셋 은 10000 으로 메 인 데이터 가 일치 하지 않 음 을 설명 합 니 다.이 때 메 인 서버 에 psync 명령 을 보 냅 니 다.
그러면 메 인 서버 는 서버 에서 전체 동기 화 를 실행 해 야 합 니까?아니면 부분 동기 화 를 실행 해 야 합 니까?부분 을 다시 동기 화하 면 메 인 서버 는 어떤 데 이 터 를 서버 에서 동기 화 하 는 지 어떻게 알 수 있 습 니까?
다음 답 은 압축 버퍼 복사 와 관련 이 있 습 니 다.
2.4.2 압축 버퍼 복사
우선,압축 버퍼 를 복사 하 는 것 은 고정된 길이 이 고 먼저 나 오 는 대기 열 입 니 다.기본 값 은 1MB 입 니 다.
홈 서버 가 명령 전 파 를 할 때 서버 뿐만 아니 라 이 버퍼 에 도 명령 을 보 냅 니 다.
따라서 압축 버퍼 를 복사 하 는 구 조 는 다음 과 같다.

서버 에서 메 인 서버 에 psync 명령 을 보 낼 때 자신의 복사 오프셋 테이프 가 필요 합 니 다.메 인 서버 는 이 복사 오프셋 과 압축 버퍼 의 오프셋 을 복사 하여 비교 할 수 있 습 니 다.
압축 버퍼 를 복사 할 때 서버 에서 의 복사 오프셋+1 후의 데이터 가 존재 하면 부분 적 인 동기 화 를 진행 합 니 다.그렇지 않 으 면 전체 동기 화 를 진행 합 니 다.
2.4.3 run id
id 를 실행 하 는 것 은 첫 번 째 복 사 를 할 때 홈 서버 는 자신의 실행 id 를 서버 에서 보 내 저장 합 니 다.
서버 에서 끊 어 진 후 서버 에서 이 실행 id 를 방금 연 결 된 메 인 서버 에 보 냅 니 다.
현재 서버 의 실행 id 가 같 으 면 서버 가 끊 기기 전에 복사 한 서버 가 현재 서버 임 을 설명 합 니 다.메 인 서버 는 일부 동기 화 를 시도 할 수 있 습 니 다.다 르 면 서버 가 끊 기기 전에 복 사 된 서버 가 현재 서버 가 아니 라 메 인 서버 가 직접 완전 동기 화 를 실행 한 다 는 것 을 의미한다.
많은 필 묵 을 써 서 마침내 부분 을 다시 동기 화하 여 다 썼 고,마지막 으로 보조 기능 을 보충 하 였 다.
2.5 심장 박동 검사
방금 언급 한 바 와 같이 주종 동기 화 와 명령 전파 두 단계 가 있다.
동기 화가 완료 되면 메 인 서버 는 명령 전파 단계 에 들 어 갑 니 다.이 때 서버 에서 1 초 에 1 번 씩 메 인 서버 에 명령 을 보 냅 니 다.REPLCONF ACK <replication_offset> 그 중에서 replicationoffset 은 서버 에서 현재 복사 오프셋 입 니 다.
이 명령 을 보 내 는 데 는 주로 세 가지 역할 이 있 습 니 다.

서버 의 네트워크 상 태 를 감지 합 니 다

min-slaves 옵션 보조 실현

검 측 명령 분실(분실 시 메 인 서버 는 잃 어 버 린 쓰기 명령 을 서버 에서 다시 보 냅 니 다)

3.총화
드디어 마지막 내용 을 다 썼 습 니 다.몇 시간 이 지 났 습 니 다.본문 내용 을 정리 해 보 겠 습 니 다.
SLAVEOF 명령 을 보 내 면 주종 동기 화 를 할 수 있 습 니 다.예 를 들 어 SLAVEOF 127.0.0.6379
주종 동기 화 는 동기 화 와 명령 전파 두 단계 가 있다.

동기 화:서버 의 데이터베이스 상태 에서 주 서버 의 현재 데이터베이스 상태 로 업데이트(자원 을 소모 하 는 작업)

명령 전파:메 인 서버 데이터베이스 상태 가 수정 되면 메 인 서버 데이터베이스 상태 가 일치 하지 않 습 니 다.이 때 메 인 데이터 에서 일치 하 는 과정

을 동기 화해 야 합 니 다.
주종 동기 화 는 첫 번 째 복사 와 끊 긴 후 두 가지 상황 을 다시 복사 합 니 다.

2.8 버 전부터 끊 긴 후에 다시 복사 하 는 상황 이 발생 할 때 메 인 서버 는 복사 오프셋,압축 버퍼 와 run id 를 복사 하여 전체 동기 화 를 실행 하 는 지,부분 동기 화 를 실행 하 는 지 확인한다

.
2.8 버 전 은 sync 명령 대신 psync 명령 을 사용 하여 동기 화 작업 을 수행 합 니 다.동기 화(sync 명령)의 비효 율 적 인 조작 을 해결 하기 위해 서다.
이상 은 이 글 의 모든 내용 입 니 다.본 고의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 참고 학습 가 치 를 가지 기 를 바 랍 니 다.여러분 의 저희 에 대한 지지 에 감 사 드 립 니 다.더 많은 내용 을 알 고 싶다 면 아래 링크 를 보 세 요.