레 디 스 의 RDB 스냅 샷 에 대해 서 말씀 드 리 겠 습 니 다.

개술
스냅 샷 이란 어떤 순간 을 기록 하 는 것 이다.예 를 들 어 우리 가 풍경 에 사진 을 찍 을 때 그 순간의 화면 과 정 보 는 한 장의 사진 에 기록 된다.
따라서 RDB 스냅 샷 은 어느 순간의 메모리 데 이 터 를 기록 하 는 것 이 고 실제 데 이 터 를 기록 하 는 것 이 며 AOF 파일 은 실제 데이터 가 아 닌 명령 으로 작 동 하 는 로 그 를 기록 합 니 다.
따라서 레 디 스 가 데 이 터 를 복구 할 때 RDB 는 AOF 보다 데이터 복구 효율 이 빨 라 집 니 다.RDB 파일 을 메모리 에 직접 읽 으 면 되 기 때문에 AOF 처럼 조작 명령 을 추가 로 실행 하 는 절차 가 필요 하지 않 아 도 데 이 터 를 복구 할 수 있 습 니 다.
다음은 RDB 스냅 샷 에 대해 구체 적 으로 이야기 하 겠 습 니 다.
2.스냅 샷 은 어떻게 사용 합 니까?
한 가 지 를 익히 려 면 먼저 어떻게 쓰 는 것 이 좋 은 방법 인지 보 자.
Redis 는 RDB 파일 을 만 드 는 두 가지 명령 을 제 공 했 습 니 다.각각save과bgsave입 니 다.그들의 차 이 는'메 인 스 레 드'에서 실 행 될 지 여부 입 니 다.

save 명령 을 실행 하면 주 스 레 드 에서 RDB 파일 을 생 성 합 니 다.실행 명령 과 같은 스 레 드 에 있 기 때문에 RDB 파일 을 너무 오래 쓰 면 주 스 레 드 를 막 습 니 다.

bgsava 명령 을 실행 하면 키 프로 세 스 를 만들어 RDB 파일 을 생 성 합 니 다.그러면 메 인 스 레 드 의 차단 을 피 할 수 있 습 니 다.

RDB 파일 의 불 러 오기 작업 은 서버 가 시 작 될 때 자동 으로 실행 되 며,Redis 는 RDB 파일 을 불 러 오 는 데 사용 할 명령 을 제공 하지 않 습 니 다.
Redis 는 또한 설정 파일 의 옵션 을 통 해 일정 시간 마다 bgava 명령 을 자동 으로 실행 할 수 있 습 니 다.기본 값 은 다음 과 같은 설정 을 제공 합 니 다.
save 900 1
save 300 10
save 60 10000
sava 라 는 옵션 을 보지 마 십시오.실제로 bgsava 명령 을 실행 합 니 다.즉,하위 프로 세 스 를 만들어 RDB 스냅 샷 파일 을 만 듭 니 다.
위의 조건 중 하 나 를 만족 시 키 면 bgava 를 실행 합 니 다.

900 초 동안 데이터 베 이 스 를 최소 1 번 수정 했다.

300 초 동안 데이터 베 이 스 를 최소 10 번 수정 했다.

60 초 동안 데이터 베 이 스 를 최소 10000 번 수정 했다.

여기 서 한 가지 만 말씀 드 리 면 Redis 의 스냅 샷 은 전체 스냅 샷 입 니 다.즉,스냅 샷 을 실행 할 때마다 메모리 에 있 는'모든 데이터'를 디스크 에 기록 합 니 다.
따라서 스냅 샷 을 실행 하 는 것 은 비교적 무 거 운 조작 으로 주파수 가 너무 잦 으 면 Redis 성능 에 영향 을 미 칠 수 있다 고 볼 수 있다.주파수 가 너무 낮 으 면 서버 가 고장 났 을 때 잃 어 버 린 데이터 가 더 많 습 니 다.
보통 스냅 샷 을 최소 5 분 에 한 번 저장 하도록 설정 할 수 있 는데 이때 Redis 가 다운 되 는 등 상황 이 발생 하면 최대 5 분 의 데 이 터 를 잃 어 버 릴 수 있다 는 뜻 이다.
이것 이 RDB 스냅 샷 의 단점 이다.서버 가 고장 이 났 을 때 AOF 보다 오래 지속 되 는 방식 으로 잃 어 버 린 데이터 가 더 많다.RDB 스냅 샷 은 전량 스냅 샷 방식 이기 때문에 실행 빈도 가 너무 빈번 해 서 는 안 된다.그렇지 않 으 면 Redis 성능 에 영향 을 줄 수 있 고 AOF 로 그 는 초 단위 로 조작 명령 을 기록 할 수 있 기 때문에 잃 어 버 린 데 이 터 는 상대 적 으로 적다.
3.bgsava 스냅 샷 을 실행 할 때 데 이 터 를 수정 할 수 있 습 니까?
그 문제 가 발생 했 습 니 다.bgava 를 실행 하 는 과정 에서 하위 프로 세 스에 맡 겨 RDB 파일 을 구축 하기 때문에 메 인 스 레 드 는 계속 작업 할 수 있 습 니 다.이때 메 인 스 레 드 는 데 이 터 를 수정 할 수 있 습 니까?
만약 데 이 터 를 수정 할 수 없다 면,이러한 성능 은 단번에 많이 떨 어 질 것 이다.데 이 터 를 수정 할 수 있다 면 어떻게 할 수 있 을 까?
결론 을 직접 말 하 세 요.bgava 를 실행 하 는 과정 에서 Redis 는 조작 명령 을 계속 처리 할 수 있 습 니 다.즉,데 이 터 는 수정 할 수 있 습 니 다.
그럼 구체 적 으로 어떻게 할 수 있 을까요?관건 적 인 기술 은 바로 쓰기 시 복제 기술(Copy-On-Write,COW)이다.
bgsava 명령 을 실행 할 때fork()를 통 해 하위 프로 세 스 를 만 듭 니 다.이 때 하위 프로 세 스 와 부모 프로 세 스 는 같은 메모리 데 이 터 를 공유 합 니 다.하위 프로 세 스 를 만 들 때 부모 프로 세 스 의 페이지 표를 복사 하지만 페이지 가 가리 키 는 물리 적 메모 리 는 하나 이기 때 문 입 니 다.

메모리 데 이 터 를 수정 할 때 만 물리 적 메모리 가 복 사 됩 니 다.

이러한 목적 은 하위 프로 세 스 를 만 들 때의 성능 손실 을 줄 이 고 하위 프로 세 스 를 만 드 는 속 도 를 가속 화하 기 위 한 것 입 니 다.하위 프로 세 스 를 만 드 는 과정 에서 메 인 스 레 드 를 막 을 수 있 기 때 문 입 니 다.
따라서 bgsave 하위 프로 세 스 를 만 든 후 부모 프로 세 스 의 모든 메모리 데 이 터 를 공유 하기 때문에 메 인 스 레 드 의 메모리 데 이 터 를 직접 읽 고 RDB 파일 에 데 이 터 를 기록 할 수 있 습 니 다.
주 스 레 드 가 공 유 된 메모리 데이터 에 대해 서도 읽 기 전용 작업 을 할 때 주 스 레 드 와 bgsave 서브 프로 세 스 는 서로 영향 을 주지 않 습 니 다.
그러나 메 인 스 레 드 가 공유 데이터 의 특정한 데이터(예 를 들 어 키 쌍A를 수정 하려 고 할 때 쓰기 시 복사 가 발생 하기 때문에 이 데이터 의 물리 적 메모리 가 복사(키 쌍A'되 고 메 인 스 레 드 는 이 데이터 사본(키 쌍A'에서 수정 작업 을 한다.이와 동시에 bgsave 서브 프로 세 스 는 원래 의 데이터(키 쌍A를 RDB 파일 에 계속 기록 할 수 있 습 니 다.
이 렇 습 니 다.Redis 는 bgsave 를 사용 하여 현재 메모리 의 모든 데 이 터 를 스냅 샷 으로 합 니 다.이 작업 은 bgsave 서브 프로 세 스 가 배경 에서 이 루어 졌 습 니 다.실행 할 때 메 인 스 레 드 를 막 지 않 습 니 다.이 는 메 인 스 레 드 가 동시에 데 이 터 를 수정 할 수 있 습 니 다.
세심 한 학생,bgsave 스냅 샷 과정 에서 메 인 스 레 드 가 공유 데 이 터 를 수정 하면 쓰기 시 복사 가 발생 한 후에 RDB 스냅 샷 은 원래 의 메모리 데 이 터 를 저장 하고 메 인 스 레 드 가 방금 수정 한 데 이 터 는 이 시간 에 RDB 파일 을 기록 하 는 방법 으로 다음 bgsave 스냅 샷 만 제출 할 수 있 습 니 다.
따라서 Redis 는 bgsave 스냅 샷 을 사용 하 는 과정 에서 메 인 스 레 드 가 메모리 데 이 터 를 수정 하면 공 유 된 메모리 데이터 든 아니 든 RDB 스냅 샷 은 메 인 스 레 드 가 수정 한 데 이 터 를 기록 할 수 없습니다.이 때 메 인 스 레 드 의 메모리 데이터 와 하위 스 레 드 의 메모리 데이터 가 분리 되 었 기 때문에 하위 스 레 드 가 RDB 파일 에 기록 한 메모리 데 이 터 는 원래 의 메모리 데이터 일 수 밖 에 없습니다.
시스템 이 RDB 스냅 샷 파일 을 만 든 후 충돌 하면 Redis 는 스냅 샷 기간 에 수 정 된 데 이 터 를 잃 어 버 립 니 다.
또 쓸 때 복사 할 때 이런 극단 적 인 상황 이 발생 한다.
Redis 가 RDB 를 지속 적 으로 실행 하 는 동안 fork 에 서 는 주 프로 세 스 와 하위 프로 세 스 가 같은 물리 적 메모 리 를 공유 하지만 도중에 주 프로 세 스 가 쓰기 동작 을 처리 하고 공유 메모 리 를 수정 하여 현재 수 정 된 데이터 의 물리 적 메모 리 를 복사 합 니 다.
그러면 극단 적 인 상황 에서 모든 공유 메모리 가 수정 되면 이때 의 메모리 사용량 은 원래 의 2 배 이다.
따라서 쓰기 동작 이 많은 장면 에 대해 우 리 는 스냅 샷 과정 에서 메모리 의 변 화 를 유의 하여 메모리 가 가득 차지 않도록 해 야 한다.
4.RDB 와 AOF 합 체
RDB 는 AOF 의 데이터 보다 회복 속도 가 빠 르 지만 스냅 샷 의 빈 도 는 파악 하기 어렵다.
만약 주파수 가 너무 낮 으 면 두 번 의 스냅 샷 사이 에 서버 가 다운 되면 비교적 많은 데 이 터 를 잃 어 버 릴 수 있다.주파수 가 너무 높 으 면 디스크 를 자주 쓰 고 하위 프로 세 스 를 만 드 는 데 추가 적 인 성능 비용 이 들 수 있 습 니 다.
RDB 회복 속도 가 빠르다 는 장점 과 AOF 손실 데이터 가 적은 장점 이 있 는 방법 은 없 을 까?
물론 있 습 니 다.그것 은 RDB 와 AOF 를 합 쳐 사용 하 는 것 입 니 다.이 방법 은 Redis 4.0 에서 제 시 된 것 입 니 다.이 방법 은 AOF 로그 와 메모리 스냅 샷 을 혼합 하여 사용 하 는 것 이 고 혼합 지구 화 라 고도 합 니 다.
혼합 지구 화 기능 을 켜 려 면 Redis 프로필 에서 아래 설정 항목 을 yes 로 설정 할 수 있 습 니 다.
aof-use-rdb-preamble yes
AOF 로그 재 작성 과정 에서 혼합 지구 화 작업 을 수행 합 니 다.
혼합 영구 화 를 열 었 을 때 AOF 에서 로 그 를 다시 쓸 때fork나 오 는 재 작성 서브 프로 세 스 는 메 인 스 레 드 와 공 유 된 메모리 데 이 터 를 RDB 방식 으로 AOF 파일 에 기록 한 다음 메 인 스 레 드 에서 처리 하 는 작업 명령 을 재 작성 버퍼 에 기록 하고 버퍼 에 있 는 증분 명령 을 AOF 방식 으로 AOF 파일 에 기록 합 니 다.쓰기 가 완료 되면 주 프로 세 스에 RDB 형식 과 AOF 형식 을 포함 하 는 AOF 파일 을 오래된 AOF 파일 로 교체 하 라 고 알 립 니 다.
혼합 지구 화 를 사 용 했 고 AOF 파일 의 앞부분 은 RDB 형식의 전량 데이터 이 며 후반 부 는 AOF 형식의 증 량 데이터 라 는 것 이다.

이러한 장점 은 Redis 로 딩 데 이 터 를 다시 시작 할 때 앞부분 이 RDB 콘 텐 츠 이기 때문에 로 딩 할 때 속도 가 빠르다 는 것 이다.
RDB 의 내용 을 불 러 온 후에 야 후반 부의 AOF 내용 을 불 러 옵 니 다.이 내용 은 Redis 백 스테이지 프로 세 스 가 AOF 를 다시 쓰 는 동안 메 인 스 레 드 가 처리 하 는 작업 명령 으로 데 이 터 를 더 적 게 잃 어 버 릴 수 있 습 니 다.
이상 은 바로 Redis RDB 스냅 샷 의 상세 한 내용 입 니 다.Redis RDB 에 관 한 자 료 는 저희 의 다른 관련 글 을 주목 해 주 십시오!