Redis에서 aof와 rdb는 무엇입니까? 차이점은 무엇입니까?-Redis-php.cn

1. RDB AOF

RDB 지속성의 차이점은 지정된 시간 간격 내에 메모리에 있는 데이터 세트의 스냅샷을 디스크에 쓰고 하위 프로세스를 포크한 후 먼저 data set 임시 파일을 작성합니다. 쓰기가 성공한 후 이전 파일을 교체하고 바이너리 압축으로 저장합니다.

특정 작업: 해시 테이블을 탐색하고, 쓰기 시 복사를 사용하고, 전체 DB 덤프를 저장합니다.
저장, 종료, 슬레이브 명령이 이 작업을 트리거합니다.
특징: 세분성이 상대적으로 큽니다. 이전에 저장, 종료, 슬레이브 충돌이 발생한 경우 중간 작업을 복원할 수 없습니다.

AOF 지속성은 서버에서 처리되는 모든 쓰기 및 삭제 작업을 로그 형식으로 기록합니다. 쿼리 작업은 기록되지 않지만, 파일을 열어 자세한 작업 기록을 볼 수 있습니다. Redis는 AOF 파일의 크기가 데이터 세트 상태를 저장하는 데 필요한 실제 크기를 초과하지 않도록 백그라운드에서 AOF 파일을 다시 작성할 수도 있습니다. Redis는 AOF 지속성과 RDB 지속성을 동시에 사용할 수도 있습니다. 이 경우 Redis가 다시 시작되면 AOF 파일을 사용하여 데이터 세트를 복원하는 데 우선 순위가 부여됩니다. 왜냐하면 AOF 파일에 저장된 데이터 세트는 일반적으로 RDB 파일에 저장된 데이터 세트보다 더 완전하기 때문입니다. 서버가 실행되는 동안에만 데이터가 존재하도록 지속성을 끌 수도 있습니다.

특징: 더 작은 세분화. 충돌 후 충돌 전에 기록할 시간이 없었던 작업만 복구할 수 없습니다.

선택 기준은 시스템이 더 높은 캐시 일관성(aof)을 위해 일부 성능을 희생할 의향이 있는지, 아니면 쓰기 작업이 빈번할 때 더 높은 성능을 위해 백업을 활성화하지 않을 의향이 있는지 확인한 다음 수동으로 확인하는 것입니다. save.를 실행한 다음 백업(rdb)을 만듭니다. RDB는 보다 궁극적으로 일관된 의미를 갖습니다.

2. AOF RDB의 장점과 단점

AOF:

장점: AOF 지속성을 사용하면 Redis의 내구성이 훨씬 더 높아집니다. fsync 없음, 초당 한 번 fsync 또는 쓸 때마다 fsync와 같은 다양한 fsync 전략을 설정할 수 있습니다. 명령이 실행됩니다. AOF의 기본 정책은 초당 한 번씩 fsync하는 것입니다. 이 구성에서 Redis는 여전히 좋은 성능을 유지할 수 있으며, 오류가 발생하더라도 최대 1초의 데이터만 손실됩니다. (fsync는 백그라운드 스레드에서 실행됩니다. 따라서 메인 스레드는 계속해서 명령 요청을 열심히 처리할 수 있습니다. AOF 파일은 추가 작업(로그만 추가)만 수행하는 로그 파일이므로 로그에 어떤 이유로 인해 불완전한 명령이 포함되어 있더라도(예: 디스크에 쓰기가 꽉 찬 경우) 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 파일의 크기는 일반적으로 RDB 파일의 크기보다 큽니다. 사용된 fsync 전략에 따라 AOF는 RDB보다 느릴 수 있습니다. 일반적인 상황에서 초당 fsync 성능은 여전히 매우 높으며, fsync를 끄면 부하가 높은 경우에도 AOF가 RDB만큼 빨라질 수 있습니다. 하지만 RDB는 막대한 쓰기 로드를 처리할 때 최대 지연 시간을 더 보장할 수 있습니다. 과거 AOF에는 이러한 버그가 있었습니다. 개별 명령으로 인해 AOF 파일을 다시 로드하면 데이터 세트를 저장했을 때의 원래 상태로 복원할 수 없습니다. (예를 들어, 차단 명령 BRPOPLPUSH는 한때 이러한 버그를 일으켰습니다.) 이 상황을 위해 테스트 모음에 테스트가 추가되었습니다. 자동으로 임의의 복잡한 데이터 세트를 생성하고 이러한 데이터를 다시 로드하여 모든 것이 정상인지 확인합니다. AOF 파일에서는 이런 종류의 버그가 흔하지 않지만, 이에 비해 RDB에서는 이런 종류의 버그가 거의 불가능합니다.

RDB의 장점:
RDB는 특정 시점의 Redis 데이터 세트를 저장하는 매우 컴팩트한 파일입니다. 이러한 종류의 파일은 백업에 매우 적합합니다. 예를 들어 지난 24시간 동안 매시간 RDB 파일을 백업할 수 있고 매월 매일 RDB 파일을 백업할 수도 있습니다. 이렇게 하면 문제가 발생하더라도 언제든지 데이터 세트를 다른 버전으로 복원할 수 있습니다. RDB는 재해 복구에 적합합니다. 파일이 하나뿐이고 콘텐츠가 매우 컴팩트하며 (암호화 후) 다른 데이터 센터나 Amazon S3로 전송할 수 있습니다. RDB는 Redis의 성능을 극대화할 수 있습니다. RDB 파일을 저장할 때 상위 프로세스가 해야 할 유일한 작업은 하위 프로세스를 분기하는 것뿐입니다. 그러면 하위 프로세스가 모든 후속 저장 작업을 처리하며 상위 프로세스는 그럴 필요가 없습니다. 디스크 I/O 작업을 수행합니다. 대규모 데이터 세트를 복원할 때 RDB는 AOF보다 빠릅니다.

단점:
서버 장애 시 데이터 손실을 방지해야 한다면 RDB는 적합하지 않습니다. Redis를 사용하면 RDB 파일 저장 빈도를 제어하기 위해 다양한 저장 지점을 설정할 수 있지만 RDB 파일은 전체 데이터 세트의 상태를 저장해야 하기 때문에 쉬운 작업이 아닙니다. 따라서 적어도 5분마다 한 번씩 RDB 파일을 저장할 수 있습니다. 이 경우 가동 중단이 발생하면 몇 분 동안의 데이터가 손실될 수 있습니다. RDB가 저장될 때마다 Redis는 하위 프로세스를 포크()해야 하며, 하위 프로세스는 실제 지속성 작업을 수행합니다. 데이터 세트가 큰 경우, fork()는 시간이 많이 소요되어 서버가 특정 밀리초 내에 클라이언트 처리를 중지하게 할 수 있습니다. 데이터 세트가 매우 크고 CPU 시간이 매우 부족하면 이 중지 시간이 발생할 수 있습니다. 심지어 1초 동안 더 길어질 수도 있습니다. AOF 재작성에도 fork()가 필요하지만, AOF 재작성 실행 간격이 아무리 길어도 데이터 내구성에는 손실이 없습니다.

위 내용은 Redis에서 aof와 rdb는 무엇입니까? 차이점은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!