Redis에는 어떤 지속성 전략이 적합합니까?

Redis는 다양한 수준의 지속성 방법을 제공합니다.

RDB 지속성은 지정된 시간 간격 내에서 데이터 세트의 특정 시점 스냅샷을 생성할 수 있습니다.

AOF는 서버에서 실행되는 모든 쓰기 작업 명령을 지속적으로 기록하고, 서버가 시작될 때 이러한 명령을 다시 실행하여 데이터 세트를 복원합니다. AOF 파일의 모든 명령은 Redis 프로토콜 형식으로 저장되며, 파일 끝에 새로운 명령이 추가됩니다. Redis는 AOF 파일의 크기가 데이터 세트 상태를 저장하는 데 필요한 실제 크기를 초과하지 않도록 백그라운드에서 AOF 파일을 다시 작성할 수도 있습니다.

Redis는 AOF 지속성과 RDB 지속성을 동시에 사용할 수도 있습니다. 이 경우 Redis가 다시 시작되면 AOF 파일을 사용하여 데이터 세트를 복원하는 데 우선 순위가 부여됩니다. 왜냐하면 AOF 파일에 저장된 데이터 세트는 일반적으로 RDB 파일에 저장된 데이터 세트보다 더 완전하기 때문입니다.

서버가 실행되는 동안에만 데이터가 존재하도록 지속성을 끌 수도 있습니다.

RDB 지식 포인트

RDB의 장점

RDB는 특정 시점의 Redis 데이터 세트를 저장하는 매우 컴팩트한 파일입니다. 이 유형의 파일은 백업 목적에 적합합니다. 예를 들어 지난 24시간 동안 매시간 RDB 파일을 백업할 수도 있고 매월 매일 RDB 파일을 백업할 수도 있습니다. 이렇게 하면 문제가 발생하더라도 언제든지 데이터 세트를 다른 버전으로 복원할 수 있습니다.

RDB는 재해 복구에 매우 적합합니다. 파일이 하나뿐이고 내용이 매우 컴팩트하며 (암호화 후) 다른 데이터 센터나 Amazon S3로 전송할 수 있습니다.

RDB는 Redis의 성능을 최대화할 수 있습니다. RDB 파일을 저장할 때 상위 프로세스가 해야 할 유일한 작업은 하위 프로세스를 포크하는 것뿐입니다. 그런 다음 하위 프로세스는 모든 후속 저장 작업을 처리하며 상위 프로세스는 필요하지 않습니다. 디스크 I/O 작업을 수행합니다.

RDB는 대규모 데이터 세트를 복원할 때 AOF보다 빠릅니다.

RDB의 단점

서버 장애 시 데이터 손실을 최소화해야 한다면 RDB는 적합하지 않습니다. Redis를 사용하면 RDB 파일 저장 빈도를 제어하기 위해 다양한 저장 지점을 설정할 수 있지만 RDB 파일은 전체 데이터 세트의 상태를 저장해야 하기 때문에 쉬운 작업이 아닙니다. 따라서 적어도 5분마다 한 번씩 RDB 파일을 저장할 수 있습니다. 이 경우 가동 중단이 발생하면 몇 분 동안의 데이터가 손실될 수 있습니다.

RDB가 저장될 때마다 Redis는 하위 프로세스를 포크()해야 하며, 하위 프로세스는 실제 지속성 작업을 수행합니다. 데이터 세트가 큰 경우, fork()는 시간이 많이 소요되어 서버가 특정 밀리초 내에 클라이언트 처리를 중지하게 할 수 있습니다. 데이터 세트가 매우 크고 CPU 시간이 매우 부족하면 이 중지 시간이 발생할 수 있습니다. 심지어 1초 동안 더 길어질 수도 있습니다. AOF 재작성에도 fork()가 필요하지만, AOF 재작성 실행 간격이 아무리 길어도 데이터 내구성에는 손실이 없습니다.

AOF 지식 포인트

AOF의 장점

AOF 지속성을 사용하면 Redis의 내구성이 훨씬 더 높아집니다. fsync 없음, 초당 한 번 fsync 또는 쓰기 명령마다 fsync와 같은 다양한 fsync 전략을 설정할 수 있습니다. 실행됩니다. AOF의 기본 정책은 초당 한 번씩 fsync하는 것입니다. 이 구성에서 Redis는 여전히 좋은 성능을 유지할 수 있으며, 오류가 발생하더라도 최대 1초의 데이터만 손실됩니다. (fsync는 백그라운드 스레드에서 실행됩니다. 따라서 메인 스레드는 계속해서 명령 요청을 열심히 처리할 수 있습니다.

AOF 파일은 추가 작업(append only log)만 수행하는 로그 파일이므로 로그에 어떤 이유로(쓰기 등) 불완전한 명령이 포함되어 있어도 AOF 파일에 쓰기에는 검색이 필요하지 않습니다. , 쓰기가 중간에 중지되는 경우 등), redis-check-aof 도구를 사용하면 이 문제를 쉽게 해결할 수도 있습니다.

Redis는 AOF 파일 크기가 너무 커지면 백그라운드에서 자동으로 AOF를 다시 작성할 수 있습니다. 다시 작성한 후의 새 AOF 파일에는 현재 데이터 세트를 복원하는 데 필요한 최소 명령 세트가 포함되어 있습니다. Redis는 새 AOF 파일을 생성하는 과정에서 계속해서 기존 AOF 파일에 명령을 추가하므로 전체 재작성 작업은 절대적으로 안전합니다. 재작성 프로세스 중에 종료가 발생하더라도 기존 AOF 파일은 손실되지 않습니다. . 새 AOF 파일이 생성되면 Redis는 이전 AOF 파일에서 새 AOF 파일로 전환하고 새 AOF 파일에 추가하기 시작합니다.

AOF 파일은 데이터베이스에서 수행되는 모든 쓰기 작업을 Redis 프로토콜 형식으로 저장하므로 AOF 파일의 내용은 매우 읽기 쉽고 읽기도 쉽습니다. 파일을 분석(구문 분석)합니다. AOF 파일 내보내기(내보내기)도 매우 간단합니다. 예를 들어 실수로 FLUSHALL 명령을 실행했지만 AOF 파일을 덮어쓰지 않은 경우 서버를 중지하고 AOF 끝에서 FLUSHALL 명령을 제거합니다. 파일을 저장하고 Redis를 다시 시작하면 FLUSHALL이 실행되기 전의 상태로 데이터 세트를 복원할 수 있습니다.

AOF의 단점

동일한 데이터 세트의 경우 일반적으로 AOF 파일의 크기가 RDB 파일의 크기보다 큽니다.

사용된 fsync 전략에 따라 AOF는 RDB보다 느릴 수 있습니다. 일반적인 상황에서 초당 fsync 성능은 여전히 ​​매우 높으며, fsync를 끄면 로드가 심한 경우에도 AOF가 RDB만큼 빨라질 수 있습니다. 그러나 RDB는 대규모 쓰기 로드를 처리할 때 더 보장된 최대 지연 시간을 제공할 수 있습니다.

AOF에는 과거에 이러한 버그가 있었습니다. 특정 명령으로 인해 AOF 파일을 다시 로드하면 데이터 세트를 저장했을 때의 원래 상태로 복원할 수 없습니다. (예를 들어, 차단 명령 BRPOPLPUSH는 한때 이러한 버그를 일으켰습니다.) 이 상황을 위해 테스트 스위트에 테스트가 추가되었습니다. 테스트는 무작위의 복잡한 데이터 세트를 자동으로 생성하고 이러한 데이터를 다시 로드하여 모든 것이 정상인지 확인합니다. AOF 파일에서는 이런 종류의 버그가 흔하지 않지만, 이에 비해 RDB에서는 이런 종류의 버그가 거의 불가능합니다.

더 많은 Redis 관련 기술 기사를 보려면 Redis Tutorial 칼럼을 방문하여 알아보세요!

위 내용은 Redis에는 어떤 지속성 전략이 적합합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!