한 기사에서 Redis의 RDB 및 AOP 지속성에 대해 알아보세요.

이 기사에서는 redis의 두 가지 지속성 메커니즘(RDB 및 AOP)에 대해 설명합니다.

Redis는 메모리 내 데이터베이스이며 데이터는 메모리에 저장됩니다. 하지만 메모리의 데이터는 빠르게 변경되고 손실되기 쉽다는 것을 우리 모두 알고 있습니다. 다행스럽게도 Redis는 RDB(Redis DataBase) 및 AOF(Append Only File)라는 지속성 메커니즘도 제공합니다. [관련 추천: Redis 동영상 튜토리얼]

여기에서는 이미 Redis의 기본 구문을 이해하고 있다고 가정합니다. 어떤 알파벳 웹사이트에 좋은 튜토리얼이 있으니 확인해 보세요. 기본적인 사용법에 대해서는 글을 쓰지 않겠습니다. 모두 일반적으로 사용되는 명령입니다.

다음은 이 두 가지 방법을 소개합니다. 얕은 것부터 깊은 것까지.

1. 지속성 프로세스

redis 데이터를 디스크에 저장할 수 있으므로 이 프로세스는 어떻게 되나요?

다음 5가지 프로세스가 필요합니다.

(1) 클라이언트가 서버에 쓰기 작업을 보냅니다(데이터는 클라이언트의 메모리에 있음).

(2) 데이터베이스 서버는 쓰기 요청의 데이터를 받습니다(데이터는 서버의 메모리에 있습니다).

(3) 서버는 write 시스템 호출을 호출하여 데이터를 디스크에 씁니다(데이터는 시스템 메모리의 버퍼에 있음).

(4) 운영 체제는 버퍼의 데이터를 디스크 컨트롤러로 전송합니다(데이터는 디스크 캐시에 있음).

(5) 디스크 컨트롤러는 디스크의 물리적 매체에 데이터를 씁니다(데이터는 실제로 디스크에 저장됩니다).

이 5가지 프로세스는 이상적인 조건에서 일반적인 저장 프로세스이지만 대부분의 경우 우리 머신 등에서는 다양한 오류가 발생합니다. 다음은 두 가지 상황입니다.

(1) Redis 데이터베이스가 실패하는 경우 세 번째 위의 단계가 완료되면 지속될 수 있으며 나머지 두 단계는 운영 체제에서 완료됩니다.

(2) 운영 체제에 오류가 발생하는 경우 위의 5단계를 완료해야 합니다.

여기에서는 저장 프로세스 중에 발생할 수 있는 오류만 고려합니다. 실제로 저장된 데이터도 손상될 수 있으므로 특정 복구 메커니즘이 필요하지만 여기서는 확장되지 않습니다. 이제 주요 고려 사항은 Redis가 위의 5단계 디스크 저장을 구현하는 방법입니다. RDB와 AOF라는 두 가지 정책 메커니즘을 제공합니다.

2. RDB 메커니즘

RDB는 실제로 스냅샷 형식으로 데이터를 디스크에 저장합니다. 스냅샷이란 현재 순간의 데이터를 사진으로 찍어 저장하는 것으로 이해하시면 됩니다.

RDB 지속성은 지정된 시간 간격 내에 디스크에 설정된 데이터의 메모리 내 스냅샷을 쓰는 것을 의미합니다. 이는 기본 지속성 방법이기도 합니다. 이 방법은 메모리의 데이터를 스냅샷 형식으로 바이너리 파일에 씁니다. 기본 파일 이름은 dump.rdb입니다.

redis를 설치한 후 모든 구성은 두 지속성 메커니즘인 RDB 및 AOF의 다양한 구성을 저장하는 redis.conf 파일에 있습니다.

RDB 메커니즘은 스냅샷을 생성하여 특정 순간의 모든 데이터를 저장하므로 이 프로세스를 구현하는 트리거 메커니즘이 있어야 합니다. RDB의 경우 저장, bgsave 및 자동화라는 세 가지 메커니즘이 제공됩니다. 하나씩 살펴보겠습니다

1. 저장 트리거 방법

이 명령은 저장 명령을 실행하는 동안 Redis는 RDB 프로세스가 완료될 때까지 다른 명령을 처리할 수 없습니다. 구체적인 과정은 다음과 같습니다.

실행 완료 시 이전 RDB 파일이 있는 경우 이전 RDB 파일을 새 파일로 교체합니다. 우리의 고객은 수만 명 또는 수십만 명이 될 수 있으므로 이 접근 방식은 분명히 바람직하지 않습니다.

2.bgsave 트리거 방법

이 명령이 실행되면 Redis는 백그라운드에서 스냅샷 작업을 비동기적으로 수행하며 스냅샷은 클라이언트 요청에도 응답할 수 있습니다. 구체적인 프로세스는 다음과 같습니다.

구체적인 작업은 Redis 프로세스가 하위 프로세스를 생성하기 위해 포크 작업을 수행한다는 것입니다. RDB 지속성 프로세스는 하위 프로세스를 담당하며 완료 후 자동으로 종료됩니다. 차단은 포크 단계에서만 발생하며 일반적으로 수명이 매우 짧습니다. 기본적으로 Redis 내부의 모든 RDB 작업은 bgsave 명령을 사용합니다.

3. 자동 트리거링

자동 트리거링은 구성 파일에 의해 수행됩니다. redis.conf 구성 파일에는 다음과 같이 설정할 수 있는 구성이 있습니다.

①save: Redis를 트리거하는 RDB 지속성 조건, 즉 메모리에 있는 데이터를 하드 드라이브에 저장할 시기를 구성하는 데 사용됩니다. 디스크. 예를 들어 "m n 저장"입니다. 데이터 세트가 m초 내에 n번 수정되면 bgsave가 자동으로 트리거됨을 나타냅니다.

기본 구성은 다음과 같습니다.

#은 900초 이내에 키 값이 1개 이상 변경되면 900개를 저장한다는 의미입니다. 1#은 300초 이내에 키 값이 10개 이상 변경되면 300개를 저장합니다. 10#은 60초 이내에 키 값이 10,000개 이상 변경되면 의미합니다. 키 변경, 저장 저장 60 10000

지속성이 필요하지 않으면 모든 저장 줄을 주석 처리하여 저장 기능을 비활성화할 수 있습니다.

②stop-writes-on-bgsave-error: 기본값은 yes입니다. RDB가 활성화되고 데이터의 마지막 백그라운드 저장이 실패한 경우 Redis가 데이터 수신을 중지할지 여부입니다. 이렇게 하면 사용자는 데이터가 디스크에 올바르게 유지되지 않았다는 사실을 알게 되며, 그렇지 않으면 누구도 재해가 발생했다는 사실을 알 수 없게 됩니다. Redis가 다시 시작되면 데이터 수신을 다시 시작할 수 있습니다

3rdbcompression; 기본값은 yes입니다. 디스크에 저장된 스냅샷의 경우 압축하여 저장할지 여부를 설정할 수 있습니다.

4rdbchecksum: 기본값은 예입니다. 스냅샷을 저장한 후 redis가 데이터 확인을 위해 CRC64 알고리즘을 사용하도록 할 수도 있지만 이로 인해 성능 소모가 약 10% 증가하게 됩니다. 최대 성능 향상을 얻으려면 이 기능을 끄면 됩니다.

⑤dbfilename: 스냅샷의 파일 이름을 설정합니다. 기본값은 dump.rdb입니다.

⑥dir: 스냅샷 파일의 저장 경로를 설정합니다. 이 구성 항목은 파일 이름이 아닌 디렉터리여야 합니다.

원하는 효과를 얻기 위해 이러한 구성을 수정할 수 있습니다. 세 번째 방법이 구성되어 있으므로 처음 두 가지 방법을 비교합니다.

4. RDB의 장점과 단점

①, 장점

(1) RDB 파일은 컴팩트하고 전체 백업이 가능하며, 백업 및 재해 복구에 이상적입니다.

(2) RDB 파일을 생성할 때 redis 메인 프로세스는 모든 저장 작업을 처리하기 위해 하위 프로세스를 포크()합니다. 메인 프로세스는 디스크 IO 작업을 수행할 필요가 없습니다.

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

② 단점

RDB 스냅샷은 메모리 데이터를 바이너리 직렬화 형태로 저장하는 전체 백업으로, 저장 공간이 매우 컴팩트합니다. 스냅샷 지속성이 수행되면 스냅샷 지속성을 담당하는 하위 프로세스가 시작됩니다. 하위 프로세스는 상위 프로세스의 메모리 데이터를 소유하게 되며, 상위 프로세스에 의한 메모리 수정 사항은 하위 프로세스에 반영되지 않습니다. 스냅샷 지속 중에 수정된 데이터는 저장되지 않으며, 데이터가 손실될 수 있습니다.

3. AOF 메커니즘

전체 백업은 항상 시간이 많이 걸립니다. 때로는 보다 효율적인 AOF 방식을 제공합니다. Redis는 쓰기 기능을 통해 수신된 모든 쓰기 명령을 매우 간단하게 만듭니다. 대중적인 이해는 로깅입니다.

1. 지속성 원칙

원칙은 아래 그림을 참조하세요.

쓰기 명령이 올 때마다 AOF 파일에 직접 저장됩니다.

2. 파일 재작성의 원리

AOF 방식은 또 다른 문제를 가져옵니다. 지속성 파일은 점점 더 커집니다. aof의 지속성 파일을 압축하기 위해. Redis는 bgrewriteaof 명령을 제공합니다. 메모리에 있는 데이터를 명령 형태로 임시 파일에 저장하는 동시에 새로운 프로세스를 포크하여 파일을 다시 작성합니다.

aof 파일을 다시 쓰는 작업은 이전 aof 파일을 읽는 것이 아니라 명령을 사용하여 메모리에 있는 전체 데이터베이스 내용을 새 aof 파일에 다시 쓰는 작업입니다.

3. AOF에는 세 가지 트리거 메커니즘이 있습니다.

(1) 항상 수정 시 동기화: 데이터 변경이 발생할 때마다 즉시 디스크에 기록됩니다. 무결성이 더 좋습니다

( 2) 매초 동기화: 비동기 작업, 매초 기록합니다. 기계가 1초 내에 다운되면 데이터가 손실됩니다.

(3) 다름: 동기화하지 않음

4.

(1) AOF can 데이터 손실을 더욱 효과적으로 방지하기 위해 일반적으로 AOF는 1초마다 백그라운드 스레드를 통해 fsync 작업을 수행하며 최대 1초의 데이터가 손실됩니다. (2) AOF 로그 파일에는 디스크 주소 지정 오버헤드가 없으며 쓰기 성능이 매우 높으며 파일이 쉽게 손상되지 않습니다.

(3) AOF 로그 파일이 너무 크더라도 백그라운드 다시 쓰기 작업은 클라이언트의 읽기 및 쓰기에 영향을 미치지 않습니다.

(4) AOF 로그 파일의 명령은 매우 읽기 쉬운 방식으로 기록됩니다. 이 기능은 치명적인 실수로 삭제된 경우의 긴급 복구에 매우 적합합니다. 예를 들어, 누군가 실수로 pushall 명령을 사용하여 모든 데이터를 지운 경우, 이때 백그라운드 재작성이 발생하지 않는 한 AOF 파일은 즉시 복사될 수 있으며 마지막 플러시all 명령이 삭제된 후 AOF 파일이 다시 저장됩니다. . 복구 메커니즘을 통해 모든 데이터를 자동으로 복구합니다

5.

(1) 동일한 데이터의 경우 AOF 로그 파일은 일반적으로 RDB 데이터 스냅샷 파일보다 큽니다.

(2) AOF가 켜진 후에는 지원되는 쓰기 QPS가 RDB에서 지원하는 쓰기 QPS보다 낮습니다. 물론 초당 1번씩 로그 파일을 fsync로 구성했는데 성능은 여전히 ​​매우 높습니다

(3) 이전에 AOF에서 기록한 로그를 통해 데이터 복구를 수행할 때 버그가 발생했습니다. 똑같은 데이터가 복구되지 않았습니다.

4. RDB와 AOF 중에서 선택하는 방법

둘을 함께 선택하면 더 좋습니다. 두 가지 지속성 메커니즘을 이해하고 있으므로 나머지는 필요에 따라 다를 수 있지만 일반적으로 조합하여 사용됩니다. 요약할 그림이 있습니다.

이러한 기능을 비교한 후 나머지는 귀하에게 달려 있습니다.

더 많은 프로그래밍 관련 지식을 보려면 프로그래밍 비디오를 방문하세요! !

위 내용은 한 기사에서 Redis의 RDB 및 AOP 지속성에 대해 알아보세요.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!