Memcache와 달리 Redis는 데이터를 하드 디스크에 유지할 수 있습니다. Redis는 현재 RDB, AOF 및 RDB-AOF 하이브리드 지속성의 세 가지 지속성 방법을 제공합니다. 데이터 보안과 백업은 운영 및 유지 관리 작업의 초점입니다. RDB 지속성의 도입 및 적용 시나리오를 살펴보겠습니다.
Redis에서 사용하는 기본 지속성 방법은 RDB입니다. RDB 파일은 공간을 거의 차지하지 않으므로 파일 생성 및 로딩 속도가 매우 빠릅니다.
RDB 파일 생성
RDB 파일 생성은 수동 방법과 자동 방법으로 나누어집니다.
먼저 수동 방법을 살펴보세요. RDB 파일 생성을 트리거할 수 있는 두 가지 명령이 있습니다. save와 bgsave의 차이점은 save 작업이 RDB 파일 생성이 완료될 때까지 redis를 차단한다는 것입니다. 그러나 bgsave는 redis를 차단하지 않으며 하위 프로세스를 분기하고 하위 프로세스에서 rdb 파일 생성을 완료합니다.
자동 방법에는 다음과 같은 여러 가지 상황이 있습니다.
현재 키 수정 작업이 redis의 Rdb 구성 요구 사항을 충족합니다
마스터-슬레이브 노드가 전체 복제를 수행하는 경우
Redis를 다시 시작하거나 종료합니다(Redis 지속성 모드는 RDB입니다)
여기에서는 RDB 관련 구성에 중점을 둡니다.
rdb 파일이 저장되는 디렉터리는 dir 구성 항목에 따라 결정됩니다
# rdb文件保存目录 dir "/usr/local/redis/var"
파일 이름은 dbfilename에 따라 결정됩니다
dbfilename "dump.rdb"
트리거 메커니즘은 저장 항목에 따라 결정됩니다
save 900 1 save 300 10 save 60 10000
위 구성의 의미는 다음과 같습니다. 1개의 수정 작업이 있을 때 트리거되고, 300초 이내에 10개의 수정 작업이 있을 때 트리거되고, 60초 이내에 10,000개의 수정 작업이 있을 때 트리거됩니다.
또한, rdbcompression 구성 항목은 rdb 파일을 압축할지 여부를 결정합니다. 기본값은 압축을 의미하는 yes이며 권장되는 방법이기도 합니다.
RDB 파일 생성 프로세스
저장이 거의 중단되었기 때문에 redis는 자동으로 bgsave 작업을 트리거하므로 여기서는 bgsave 프로세스만 소개합니다.
bgsave 실행 시 현재 자식 프로세스가 있는 경우 redis는 다음 작업을 수행하지 않고 바로 종료됩니다. 그렇지 않은 경우 실행을 계속합니다.
redis 기본 프로세스는 하위 프로세스를 분기합니다. Fork 중에는 Redis가 차단되지만 시간은 매우 짧습니다.
포크가 성공한 후에도 Redis 기본 프로세스는 해야 할 일을 계속 수행합니다.
하위 프로세스는 새 RDB 파일을 생성하고 이전 파일을 대체합니다.
교체 작업이 완료되면 하위 프로세스는 상위 프로세스에 알리고 상위 프로세스는 이 작업과 관련된 정보를 저장합니다.
애플리케이션 시나리오
RDB 파일은 크기가 작고 생성 및 로드가 빠릅니다. 그러나 RDB 지속성 방법은 실시간 지속성을 달성할 수 없으며 비정상적인 상황에서 쉽게 데이터 손실로 이어질 수 있습니다. 또한 다른 버전의 rdb 파일은 호환되지 않을 수 있습니다.
위의 소개를 통해 RDB 파일은 매일 이른 아침 RDB 파일을 생성하는 등 재해 복구 백업에 매우 적합하다는 것을 알 수 있습니다. 또한 캐싱을 위해 Redis를 사용하고 일부 데이터 손실이 영향을 미치지 않는 등 Redis에 저장된 데이터가 그다지 중요하지 않은 경우 일반적으로 RDB를 사용하는 것이 더 나은 방법입니다.
일반적인 문제에 대한 또 다른 솔루션 소개: Redis 데이터가 저장된 파티션이 거의 가득 찼을 때 Redis를 중지하지 않고 다른 파티션에 데이터를 쓰는 방법. config set dir 'new partitiondirectory'를 사용하여 rdb 파일이 저장된 디렉토리를 수정할 수 있습니다. 그런 다음 bgsave를 실행하여 새 디렉터리에 새 RDB 파일을 생성합니다.
위 내용은 Redis 데이터 지속성을 위한 RDB의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!