목차
메인 스레드, 하위 프로세스, 백그라운드 스레드 간의 연결과 차이점은 무엇입니까?
Redis 지속성 프로세스에 다른 잠재적인 차단 위험이 있습니까?
마스터 라이브러리와 슬레이브 라이브러리 간의 복제에 AOF를 사용하지 않는 이유는 무엇입니까?
잠금 만료 시간을 평가하기 어려운 경우 어떻게 해야 합니까?
Watchdog 코드를 추가하여 분산 잠금을 구현합니다.
지구화
Redis는 인메모리 데이터베이스이지만 Redis는 RDB와 AOF라는 두 가지 지속성 메커니즘을 지원합니다. 디스크에 데이터를 쓰면 프로세스 종료로 인한 데이터 손실을 효과적으로 방지할 수 있습니다. 이는 다음에 다시 시작할 때 이전에 유지된 파일을 사용하여 달성할 수 있습니다. .
RDB
RDB 지속성은 현재 프로세스 데이터의 스냅샷을 생성하고 이를 하드 디스크에 저장하는 프로세스입니다. 소위 메모리 스냅샷은 특정 순간에 메모리에 있는 데이터의 상태 기록을 말합니다. 이는 사진과 비슷하며, 친구의 사진을 찍으면 그 순간의 친구의 모습이 사진 한 장에 완벽하게 기록될 수 있습니다. RDB는 Redis DataBase의 약자입니다.
어떤 메모리 데이터를 스냅샷해야 합니까?
Redis의 데이터는 모두 메모리에 저장되어 있으며, 모든 데이터의 신뢰성을 보장하기 위해 전체 스냅샷(full snapshot), 즉 메모리에 있는 모든 데이터를 디스크에 기록한다. 그러나 RDB 파일이 클수록 디스크에 데이터를 쓰는 데 드는 시간 오버헤드가 커집니다.
RDB 파일이 생성되면 메인 스레드가 차단되나요?
Redis는 RDB 파일을 생성하는 두 가지 수동 명령(save 및 bgsave)을 제공합니다.
save: 메인 스레드에서 실행되면 차단이 발생하며, 상대적으로 메모리가 큰 인스턴스의 경우 장기간 차단이 발생하므로 온라인 환경에서는 권장되지 않습니다. bgsave: 메인 스레드의 차단을 피하면서 RDB 파일 작성을 위해 특별히 하위 프로세스를 생성합니다. 이는 Redis RDB 파일 생성을 위한 기본 구성이기도 합니다.
지휘 실습 시연
명령을 실행하여 수동으로 트리거하는 것 외에도 Redis 내부에는 다음 시나리오와 같이 RDB를 자동으로 트리거하는 지속성 메커니즘도 있습니다.
1) "save mn"과 같은 저장 관련 구성을 사용하십시오. 데이터 세트가 m초 내에 n번 수정되면 bgsave가 자동으로 트리거됨을 나타냅니다.
2) 슬레이브 노드가 전체 복사 작업을 수행하면 마스터 노드는 자동으로 bgsave를 실행하여 RDB 파일을 생성하고 이를 슬레이브 노드로 보냅니다.
3) Redis를 다시 로드하기 위해 debug reload 명령을 실행하면 저장 작업도 자동으로 트리거됩니다.
4) 기본적으로 shutdown 명령 실행 시 AOF 지속성 기능이 활성화되어 있지 않으면 bgsave가 자동으로 실행됩니다.
RDB 지속성을 끄려면 과정에 설명된 Redis 버전(6.2.4)에서 구성 파일의 저장 구성을 ""를 저장하도록 변경합니다.
bgsave 실행 프로세스
스냅샷을 위해 쓰기 작업을 일시 중지하는 것은 확실히 용납되지 않습니다. 따라서 이때 Redis는 운영 체제에서 제공하는 COW(기록 중 복사) 기술을 사용하여 스냅샷을 수행하는 동안 쓰기 작업을 정상적으로 처리하게 됩니다.
bgsave 하위 프로세스는 메인 스레드의 포크에 의해 생성되며 메인 스레드의 모든 메모리 데이터를 공유할 수 있습니다. bgsave 하위 프로세스가 실행된 후 기본 스레드의 메모리 데이터를 읽기 시작하고 이를 RDB 파일에 씁니다.
메인 스레드가 이러한 데이터에 대한 읽기 작업도 수행하는 경우(예: 그림의 키-값 쌍 A), 메인 스레드와 bgsave 하위 프로세스는 서로 영향을 미치지 않습니다. 그러나 메인 스레드가 데이터 조각(예: 그림의 키-값 쌍 B)을 수정하려는 경우