Redis를 지속하는 방법에는 여러 가지가 있습니다.

Redis는 고급 키-값 데이터베이스입니다. Memcached와 유사하지만 데이터가 유지될 수 있고 광범위한 데이터 유형을 지원합니다. 문자열, 연결 목록, 집합, 정렬 집합이 있습니다. 서버 측에서 집합의 합집합, 교집합, 보수(차이) 계산을 지원하고 다양한 정렬 기능도 지원합니다. 따라서 Redis는 데이터 구조 서버로도 간주될 수 있습니다.

Redis의 모든 데이터는 메모리에 저장된 다음 때때로 비동기식으로 디스크에 저장됩니다(이를 "반영구" 모드라고 함). ; 모든 데이터 변경 사항을 추가 전용 파일(aof)에 쓸 수도 있습니다(이를 "전체 지속성 모드"라고 함).

Redis 데이터는 메모리에 저장되므로 Persistence를 설정하지 않으면 Redis 재시작 후 모든 데이터가 손실됩니다. 따라서 데이터를 디스크에 저장하려면 Redis의 Persistence 기능을 활성화해야 합니다. Redis가 다시 시작된 후 디스크에서 데이터를 복원할 수 있습니다.

redis는 지속성을 위한 두 가지 방법을 제공합니다. 하나는 RDB 지속성(원칙은 메모리에 있는 Reids의 데이터베이스 레코드를 디스크의 RDB 지속성으로 주기적으로 덤프하는 것입니다)이고, 다른 하나는 AOF( 파일만 추가) 지속성(파일에 Reids의 작업 로그를 추가 방식으로 기록하는 것이 원칙).

그럼 이 두 지속성 방법의 차이점은 무엇이며 어떻게 선택해야 할까요?

RDB 지속성은 지정된 시간 간격 내에 메모리에 있는 데이터 세트의 스냅샷을 디스크에 쓰는 것을 의미합니다. 실제 작업 프로세스는 하위 프로세스를 포크하고 먼저 데이터 세트를 디스크에 쓰는 것입니다. a 임시 파일이 성공적으로 작성된 후 이전 파일을 바이너리 압축을 사용하여 교체하고 저장합니다.

AOF 지속성은 서버에서 처리되는 모든 쓰기 및 삭제 작업을 로그 형식으로 기록합니다. 쿼리 작업은 기록되지 않지만, 파일을 열어서 자세한 작업 기록을 볼 수 있습니다.

둘의 장점과 단점

RDB의 장점은 무엇인가요?

1) 이 방법을 채택하면 전체 Redis 데이터베이스에 파일이 하나만 포함되므로 파일 백업에 적합합니다. 예를 들어 지난 24시간 동안의 데이터를 매시간 보관하고 지난 30일의 데이터를 매일 보관하도록 계획할 수 있습니다. 이러한 백업 전략을 통해 시스템에 치명적인 장애가 발생하면 매우 쉽게 복원할 수 있습니다.

2) 재해 복구에는 RDB가 매우 좋은 선택입니다. 단일 파일을 쉽게 압축한 다음 다른 저장 매체로 전송할 수 있기 때문입니다.

3). Redis 서비스 프로세스의 경우 지속성을 시작할 때 해야 할 일은 하위 프로세스를 분기하는 것뿐입니다. 그러면 하위 프로세스가 지속성 작업을 완료합니다. 이렇게 하면 IO 작업을 수행하는 서비스 프로세스를 크게 피할 수 있습니다.

4) AOF 메커니즘과 비교하여 데이터 세트가 크면 RDB 시작 효율성이 더 높아집니다.

RDB의 단점은 무엇인가요?

1) 데이터의 높은 가용성을 보장하려는 경우, 즉 데이터 손실을 최대한 방지하려는 경우 RDB는 좋은 선택이 아닙니다. 예약된 지속성 전에 시스템이 충돌하면 디스크에 쓸 시간이 없었던 데이터가 손실되기 때문입니다.

2) RDB는 포크 하위 프로세스를 통해 데이터 지속성을 지원하므로 데이터 세트가 큰 경우 전체 서버가 수백 밀리초 또는 심지어 1초 동안 서비스를 중지할 수 있습니다.

AOF의 장점은 무엇인가요?

1) 이 메커니즘은 더 높은 데이터 보안, 즉 데이터 지속성을 가져올 수 있습니다. Redis는 세 가지 동기화 전략, 즉 매초 동기화, 수정마다 동기화, 동기화 없음을 제공합니다. 실제로 매 초 동기화도 비동기식으로 완료되며 효율성도 매우 높습니다. 유일한 차이점은 시스템이 다운되면 이 초 내에 수정된 데이터가 손실된다는 것입니다. 수정 사항이 동기화될 때마다 이를 동기식 지속성이라고 생각할 수 있습니다. 즉, 발생하는 모든 데이터 변경 사항이 즉시 디스크에 기록됩니다. 이 방법은 효율성이 가장 낮을 것으로 예측할 수 있습니다. 동기화가 없다는 것은 더 말할 필요도 없이 모두가 정확하게 이해할 수 있다고 생각합니다.

2) 이 메커니즘은 로그 파일 쓰기에 추가 모드를 사용하므로 쓰기 프로세스 중에 가동 중지 시간이 발생하더라도 로그 파일의 기존 콘텐츠는 삭제되지 않습니다. 그러나 이 작업에서 데이터의 절반만 쓰고 시스템 충돌이 발생하더라도 걱정하지 마십시오. 다음에 Redis가 시작되기 전에 redis-check-aof 도구를 사용하여 데이터 일관성 문제를 해결할 수 있습니다.

3) 로그가 너무 크면 Redis가 자동으로 다시 쓰기 메커니즘을 활성화할 수 있습니다. 즉, Redis는 수정된 데이터를 추가 모드에서 이전 디스크 파일에 지속적으로 기록하는 동시에 이 기간 동안 어떤 수정 명령이 실행되었는지 기록하기 위해 새 파일도 생성합니다. 따라서 다시 쓰기 전환을 수행할 때 데이터 보안이 더 잘 보장될 수 있습니다.

4) AOF에는 모든 수정 작업을 기록하기 위한 명확하고 이해하기 쉬운 형식의 로그 파일이 포함되어 있습니다. 실제로 이 파일을 통해 데이터 재구성을 완료할 수도 있습니다.

AOF의 단점은 무엇인가요?

1) 동일한 수의 데이터 세트의 경우 AOF 파일은 일반적으로 RDB 파일보다 큽니다. 대규모 데이터 세트를 복원할 때 RDB는 AOF보다 빠릅니다.

2) 동기화 전략에 따라 AOF는 운영 효율성 측면에서 RDB보다 느린 경우가 많습니다. 간단히 말해서, 초당 동기화 전략의 효율성은 상대적으로 높으며, 동기화 비활성화 전략의 효율성은 RDB만큼 효율적입니다.

둘 중 하나를 선택하는 기준은 시스템이 더 높은 캐시 일관성(aof)을 위해 일부 성능을 희생할 의향이 있는지, 아니면 쓰기 작업이 중단될 때 더 높은 성능을 위해 백업을 활성화하지 않을 의향이 있는지 확인하는 것입니다. 저장시에는 백업(rdb)을 해두시기 바랍니다. RDB는 보다 궁극적으로 일관된 의미를 갖습니다.

위 내용은 Redis를 지속하는 방법에는 여러 가지가 있습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!