Redis 주종 복제 원리

참고:http://wwdhks.blog.51cto.com/839773/1338781
Redis 는 서버 (slave server) 에서 주 서버 (master server) 로 정확 한 복제품 을 만 들 수 있 는 간단 하고 사용 하기 쉬 운 메 인 복사 (master - slave replication) 기능 을 지원 합 니 다.
다음은 Redis 복제 기능 에 관 한 몇 가지 중요 한 부분 입 니 다.
Redis 는 비동기 복 제 를 사용 합 니 다.Redis 2.8 부 터 는 서버 에서 1 초 에 한 번 씩 주 서버 에 복사 흐름 (replication stream) 의 처리 진 도 를 보고 합 니 다.
메 인 서버 하나 에 여러 개의 서버 가 있 을 수 있다.
메 인 서버 는 서버 뿐만 아니 라 서버 에서 도 자신의 서버 가 있 을 수 있 으 며, 여러 서버 사이 에서 하나의 도형 구 조 를 구성 할 수 있다.
복사 기능 은 메 인 서버 를 막 지 않 습 니 다. 서버 에서 하나 이상 의 동기 화가 진행 되 고 있 더 라 도 메 인 서버 는 명령 요청 을 계속 처리 할 수 있 습 니 다.
복사 기능 도 서버 에서 막 히 지 않 습 니 다: redis.conf 파일 에 해당 하 는 설정 이 있 습 니 다. 서버 에서 첫 동기 화가 진행 되 고 있 더 라 도 서버 는 이전 버 전의 데이터 세트 를 사용 하여 명령 조 회 를 처리 할 수 있 습 니 다.단, 서버 에서 오래된 버 전 데이터 세트 를 삭제 하고 새 버 전 데이터 세트 를 불 러 오 는 동안 연결 요청 이 막 힐 수 있 습 니 다.서버 에서 홈 서버 와 의 연결 이 끊 겼 을 때 클 라 이언 트 에 오 류 를 보 낼 수 있 도록 설정 할 수 있 습 니 다.
복사 기능 은 단순히 데이터 중복 (data redundancy) 에 사용 할 수도 있 고 서버 에서 명령 만 읽 기 요청 을 처리 하여 확장 성 (scalability) 을 향상 시 킬 수도 있 습 니 다. 예 를 들 어 복잡 한 것 입 니 다. SORT 명령 은 부속 노드 에 맡 겨 실행 할 수 있다.
복사 기능 을 통 해 메 인 서버 가 지속 적 인 작업 을 하지 않도록 할 수 있 습 니 다. 메 인 서버 의 지속 적 인 기능 을 닫 은 다음 서버 에서 지속 적 인 작업 을 수행 하면 됩 니 다.
복제 기능 의 작 동 원리
첫 번 째 연결 이 든 재 연결 이 든 서버 를 만 들 때 서버 에서 메 인 서버 로 보 냅 니 다. SYNC 명령
받다 SYNC 명령 의 홈 서버 가 실 행 됩 니 다. BGSAVE ，작업 실행 을 저장 하 는 동안 새로 실 행 된 기록 명령 을 버퍼 에 저장 합 니 다.
... 해 야 한다 BGSAVE 실행 이 완료 되면 메 인 서버 는 저장 작업 을 수행 합 니 다. .rdb 서버 에서 파일 을 보 내 고 서버 에서 이 걸 받 습 니 다. .rdb 파일, 그리고 파일 의 데 이 터 를 메모리 에 불 러 옵 니 다.
이후 메 인 서버 는 레 디 스 명령 프로 토 콜 형식 으로 명령 버퍼 에 쌓 인 모든 내용 을 서버 에 보 냅 니 다.
telnet 명령 을 통 해 이 동기 화 과정 을 직접 검증 할 수 있 습 니 다. 먼저 명령 요청 을 처리 하고 있 는 Redis 서버 를 연결 한 다음 보 낼 수 있 습 니 다. SYNC 명령, 시간 이 지나 면 telnet 세 션 (session) 이 서버 에서 보 내 온 큰 데이터 (rdb) 를 볼 수 있 습 니 다. 파일), 그리고 서버 에서 실 행 된 모든 쓰기 명령 을 telnet 세 션 으로 다시 보 냅 니 다.
여러 개가 서버 에서 메 인 서버 로 동시에 보 내 더 라 도 SYNC ，홈 서버 도 한 번 만 실행 하면 됩 니 다. BGSAVE 명령 은 서버 에서 동기 화 요청 을 모두 처리 할 수 있 습 니 다.
서버 에서 홈 서버 간 연결 이 끊 겼 을 때 자동 으로 재 접속 할 수 있 으 며, Redis 2.8 버 전에 서 끊 긴 후 다시 연 결 된 것 은 서버 에서 전체 재 동기 화 (full resynchronization) 작업 을 수행 해 야 하지만, Redis 2.8 버 전부터 서비스 기 는 홈 서버 의 상황 에 따라 전체 재 동기 화 를 실행 할 지, 일부 재 동기 화 를 실행 할 지 선택 할 수 있 습 니 다.（partial resynchronization）。
동기 화 단계:
(1) Slave 서버 가 Master 서버 에 연결 되 어 있 습 니 다.
(2) 슬 레이 브 서버 에서 SYCN 명령 을 보 냅 니 다.
(3) Master 서버 에서 데이터 베 이 스 를. rdb 파일 로 백업 합 니 다.
(4) Master 서버 는. rdb 파일 을 Slave 서버 에 전송 합 니 다.
(5) Slave 서버 는. rdb 파일 데 이 터 를 데이터베이스 에 가 져 옵 니 다.
위의 5 단 계 는 동기 화 첫 번 째 단계 입 니 다. 그 다음 에 Master 서버 에서 모든 명령 을 호출 할 때 ReplicationFeedSlaves () 를 사용 하여 Slave 서버 에 동기 화 합 니 다. Master 와 Slave 사이 의 링크 가 끊 기 면 Slave 는 자동 으로 Master 를 다시 연결 할 수 있 지만 연결 이 성공 한 후에 한 번 의 완전 동기 화 는 자동 으로 실 행 됩 니 다.
부분 동기 화
Redis 2.8 부터 네트워크 연결 이 일시 적 으로 실 효 된 후에 서버 에서 기 존의 복사 프로 세 스 (process) 를 계속 실행 하려 고 시도 할 수 있 습 니 다. 완전한 동기 화 작업 을 수행 하지 않 아 도 됩 니 다.
이 기능 은 메 인 서버 가 보 낸 복사 흐름 을 위해 메모리 버퍼 (in - memory backlog) 를 만 들 고 메 인 서버 와 모든 서버 간 에 복사 오프셋 (replication offset) 과 메 인 서버 ID (master run id) 를 기록 해 야 합 니 다.네트워크 연결 이 끊 겼 을 때 서버 에서 다시 연결 하고 홈 서버 에 원래 의 복사 프로 세 스 를 계속 실행 할 것 을 요청 합 니 다.
서버 에 기 록 된 메 인 서버 ID 가 현재 연결 할 메 인 서버 의 ID 와 같 고 서버 에 기 록 된 오프셋 에서 지정 한 데 이 터 를 메 인 서버 의 복사 스 트림 버퍼 에 저장 하면 메 인 서버 는 서버 에서 끊 겼 을 때 부족 한 데 이 터 를 보 낸 다음 복사 작업 을 계속 수행 할 수 있 습 니 다. 그렇지 않 으 면 서버 에서 전체 동기 화 작업 을 수행 해 야 합 니 다. Redis 2.8 의 이 부분 은 동기 화 기능 이 새로 추 가 된 것 을 사용 합 니 다. PSYNC 내부 명령, Redis 2.8 이전 버 전 은 SYNC 명령, 단, 서버 가 Redis 2.8 이상 버 전이 라면 홈 서버 버 전에 따라 사용 여 부 를 결정 합 니 다. PSYNC 역시 SYNC ：
홈 서버 가 Redis 2.8 이상 버 전이 라면 서버 에서 사용 합 니 다. PSYNC 동기 화 를 명령 합 니 다. 홈 서버 가 Redis 2.8 이전 버 전이 라면 서버 에서 사용 합 니 다. SYNC 동기 화 를 명령 합 니 다. 배치 하 다.
서버 에서 설정 하 는 것 은 매우 간단 합 니 다. 설정 파일 에 다음 줄 을 추가 하면 됩 니 다.

slaveof 192.168.1.1 6379

물론 코드 에 있 는 192.168.1.1 화해시키다 6379 홈 서버 의 IP 와 포트 번호 로 바 꿉 니 다.
다른 방법 은 호출 이다. SLAVEOF 명령, 홈 서버 의 IP 와 포트 를 입력 하고 동기 화하 면 시 작 됩 니 다.

127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
OK

서버 에서 만 읽 기
Redis 2.6 부터 서버 에서 읽 기 전용 모드 를 지원 하 며 이 모드 는 서버 의 기본 모드 입 니 다.
읽 기 전용 모드 redis.conf 파일 의 slave-read-only 옵션 제어 CONFIG SET 명령 으로 이 모드 를 켜 거나 닫 습 니 다.
서버 에서 만 읽 으 면 쓰기 명령 을 거부 하기 때문에 작업 실수 로 데 이 터 를 서버 에서 기록 하 는 경우 가 발생 하지 않 습 니 다.
서버 에서 만 읽 어도 DEBUG 화해시키다 CONFIG 등 관리 식 명령 은 여전히 사용 할 수 있 기 때문에 서버 를 인터넷 이나 신뢰 할 수 없 는 네트워크 에 노출 시 켜 서 는 안 됩 니 다. 단, 사용 합 니 다. redis.conf 명령 이름 변경 옵션 을 사용 하면 서버 에서 만 읽 을 수 있 는 보안 을 향상 시 킬 수 있 습 니 다.
서버 에서 작성 한 데 이 터 는 동기 화 된 데이터 로 덮어 쓸 수도 있 고 서버 에서 다시 시작 할 때 잃 어 버 릴 수도 있 습 니 다. 그런데 왜 서버 에서 쓸 수 있 는 데 이 터 를 만들어 야 합 니까?
일부 중요 하지 않 은 임시 데 이 터 는 서버 에서 저장 할 수 있 기 때 문 입 니 다. 예 를 들 어 클 라 이언 트 는 서버 에서 메 인 서버 의 접근 성 (reachability) 정 보 를 저장 하여 고장 이전 (failover) 정책 을 실현 할 수 있 습 니 다.
서버 관련 설정
하면, 만약, 만약... requirepass 비밀 번 호 를 설정 하면 서버 에서 동기 화 작업 이 순조롭게 진행 되도록 서버 에서 인증 설정 을 해 야 합 니 다.
실행 중인 서버 에 대해 클 라 이언 트 로 다음 명령 을 입력 할 수 있 습 니 다.

config set masterauth 

이 암 호 를 영구적 으로 설정 하려 면 설정 파일 에 추가 할 수 있 습 니 다.

masterauth 

또한 메 인 서버 실행 부분 이 동기 화 될 때 사용 하 는 복사 스 트림 버퍼 와 관련 된 몇 가지 옵션 이 있 습 니 다. 자세 한 정 보 는 Redis 소스 코드 에 첨부 된 것 을 참고 할 수 있 습 니 다. redis.conf 예제 파일.
메 인 서버 는 최소한 N 개 이상 의 서버 에서 만 쓰기 동작 을 수행 합 니 다.
Redis 2.8 부터 데이터 의 안전성 을 확보 하기 위해 설정 을 통 해 주 서버 가 현재 서버 에서 연 결 된 최소한 N 개 만 있 는 상태 에서 쓰기 명령 을 수행 할 수 있 도록 합 니 다.
그러나 레 디 스 는 비동기 복 제 를 사용 하기 때문에 메 인 서버 에서 보 낸 쓰기 데이터 가 반드시 서버 로부터 받 아들 여 지 는 것 은 아니 므 로 데이터 분실 가능성 은 여전히 존재 한다.
다음은 이 특성의 작 동 원리 이다.
서버 에서 초당 한 번 주파수 PING 메 인 서버 로 복사 흐름 처리 상황 을 보고 합 니 다. 홈 서버 는 서버 에서 마지막 으로 PING 를 보 내 는 시간 을 기록 합 니 다. 사용 자 는 설정 을 통 해 네트워크 지연 의 최대 값 을 지정 할 수 있 습 니 다. min-slaves-max-lag ，쓰기 작업 을 수행 하 는 데 필요 한 최소한 서버 수 min - slaves - to - write 。
하면, 만약, 만약... min-slaves-to-write 서버 에서, 그리고 이 서버 들 의 지연 값 은 min-slaves-max-lag 초, 그러면 메 인 서버 에서 클 라 이언 트 가 요청 한 쓰기 동작 을 수행 합 니 다.
이 기능 을 CAP 이론 에서 C 의 조건 완화 버 전 으로 볼 수 있 습 니 다. 쓰기 작업 의 지속 성 을 보장 할 수 는 없 지만 데 이 터 를 잃 어 버 린 창 은 지정 한 초 로 엄 격 히 제 한 됩 니 다.
다른 한편, 조건 이 미 치지 못 하면 min-slaves-to-write 화해시키다 min-slaves-max-lag 지정 한 조건 이 있 으 면 쓰기 동작 이 실행 되 지 않 습 니 다. 홈 서버 는 쓰기 동작 을 요청 한 클 라 이언 트 에 게 오 류 를 되 돌려 줍 니 다.
다음은 이 기능 의 두 가지 옵션 과 필요 한 인자 입 니 다.
min-slaves-to-writeofslaves>
min-slaves-max-lagofseconds>
자세 한 정 보 는 Redis 소스 코드 에 첨부 된 것 을 참고 할 수 있 습 니 다. redis.conf 예제 파일.