여러 가지 Redis 지속성 방법 소개

1. 소개

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

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

Redis 데이터는 메모리에 저장되므로 지속성을 구성하지 않으면 Redis를 다시 시작한 후 모든 데이터가 손실됩니다. 따라서 Redis를 다시 시작한 후 데이터를 디스크에 저장하려면 Redis의 지속성 기능을 활성화해야 합니다. 디스크에서 데이터 복구부터 시작하세요.

redis는 지속성을 위한 두 가지 방법을 제공합니다, 하나는 RDB 지속성(메모리에 있는 Reids의 데이터베이스 레코드를 디스크의 RDB 지속성에 주기적으로 덤프하는 것이 원칙)이고, 다른 하나는 AOF(append only file ) 지속성(원칙은 다음과 같습니다)입니다. Reids의 작업 로그를 파일에 추가하여 기록합니다.) 그렇다면 이 두 가지 지속성 방법의 차이점은 무엇이며 어떻게 선택해야 할까요? 내가 인터넷에서 읽은 대부분의 정보에는 이 두 가지 방법을 구성하고 사용하는 방법이 소개되어 있지만 두 가지 방법의 차이점과 사용되는 응용 시나리오에 대해서는 설명하지 않습니다.

2. 둘의 차이점

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

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

3. 둘의 장점과 단점

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는 보다 궁극적으로 일관된 의미를 갖습니다.

4. 일반 구성

RDB 지속성 구성

Redis는 데이터 세트의 스냅샷을 dump.rdb 파일에 덤프합니다. 또한 구성 파일을 통해 Redis 서버 덤프 스냅샷의 빈도를 수정할 수도 있습니다. 6379.conf 파일을 연 후 save를 검색하면 다음 구성 정보를 볼 수 있습니다.                               그 후, 적어도 1 주요 변경 사항이 있으면 메모리 스냅샷을 덤프하세요.

save 300 10 #300초(5분) 후 10개 이상의 키가 변경된 경우 메모리 스냅샷을 덤프합니다.

save 60 10000 #60초(1분) 후 10000개 이상의 키가 변경된 경우 메모리 스냅샷을 덤프합니다.

AOF 지속성 구성

Redis 구성 파일에는 세 가지 동기화 방법이 있습니다.

appendfsync Always #데이터 수정이 발생할 때마다 AOF 파일이 기록됩니다.

appendfsynceverysec #초마다 한 번씩 동기화하는 전략은 AOF의 기본 전략입니다.

appendfsync no         #동기화하지 않음. 효율적이지만 데이터가 유지되지 않습니다.

더 많은 Redis 지식을 알고 싶다면

redis 데이터베이스 튜토리얼

칼럼을 주목해 주세요.

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