❝
이 문서에서는 지식 포인트를 설명합니다. 지속성 소개 RDB AOF RDB와 AOF의 차이점 Persistence 적용 시나리오
❞

Foreword

❝
Kaka는 로드맵을 정리하고 인터뷰 가이드를 작성하며 그러한 로드맵에 따라 기사를 작성하려고 준비했지만 나중에 보충 자료가 없음을 확인했습니다. 지식 포인트가 추가됩니다. 또한 귀하의 파트너가 참여하여 도움을 추가할 수 있기를 기대합니다. 댓글 섹션에서 만나요!
❞

이 문서에서는 Redis 지속성의 전체 버전을 이해하는 데 도움이 됩니다. — 여기에 이미지 설명 삽입

데모 환경

centos7.0 레디스4.0 Redis 저장 디렉터리:/usr/local/redis redis.conf 저장 디렉터리:/usr/local/redis/data

1. 지속성 소개

Redis의 모든 데이터는 메모리에 저장됩니다. Redis가 충돌하면 데이터가 손실됩니다. Redis 지속성은 데이터를 디스크에 저장하는 것입니다. 영구 저장 매체를 사용하여 데이터 프로세스를 저장하고 저장된 데이터를 특정 시간에 복원하는 작업 메커니즘을 지속성이라고 합니다.

지속성 과정에서 무엇이 저장되나요?

첫 번째 스냅샷 형식은 데이터 결과를 저장하고 데이터에 중점을 두는데, 이는 아래에서 설명하는 RDB입니다.

두 번째 작업 프로세스는 작업 프로세스를 저장하며 데이터 작업 프로세스에 중점을 둡니다. 아래에서 다룰 AOF

2.RDB

2-1 RDB 시작 방법 - save 명령어

다음 그림은 redis.conf 설정 정보, 이후 실행 저장 후 dump.rdb 파일이 생성됩니다 이 문서에서는 Redis 지속성의 전체 버전을 이해하는 데 도움이 됩니다. 이제 값을 설정하고 저장하면 /usr/local/redis/data

에 dump6379.rdb 파일이 생성됩니다.

2-2 RDB 시작 모드 -- save 명령 관련 구성

dbfilename dump6379.rdb: 로컬 데이터베이스 파일 이름을 설정하며, 기본값은 dump.rdb
dir: 저장 rdb 파일 경로
rdbcompression yes: 로컬 데이터베이스에 저장할 때 데이터를 압축할지 여부를 설정합니다. 기본값은 lzf 압축을 사용하는 yes입니다.
rdbchecksum yes: RDB 파일 형식 확인을 처리할지 여부를 설정합니다. 이 검증 과정은 파일을 쓰고 읽을 때 사용됩니다. 파일 과정은 모두 수행됩니다

2-3 RDB 데이터 복구

사실, 이 데이터 복구는 다른 관계형 데이터베이스 복구에 비해 기본적으로 작동하지 않습니다. 그냥 다시 시작하세요

2-4 RDB -- 저장 명령 작동 방식

이 사진은 온라인 비디오에서 가져온 것입니다. save 명령을 실행하면 현재 RDB 프로세스가 완료될 때까지 현재 Redis 서버가 차단되므로 장기적인 차단이 발생할 수 있습니다. 이 명령은 기본적으로 폐기되어 작업 과정에서 더 이상 사용되지 않습니다. 모두 bgsave 이 문서에서는 Redis 지속성의 전체 버전을 이해하는 데 도움이 됩니다.

로 교체하겠습니다.

2-5 RDB -- How the bgsave command works

이 문서에서는 Redis 지속성의 전체 버전을 이해하는 데 도움이 됩니다. redis에서 bgsave를 실행하면 Background saving start가 바로 반환됩니다

이때 로그 파일을 살펴보고 있습니다. bgsave 명령은 차단 문제의 저장 최적화 이 문서에서는 Redis 지속성의 전체 버전을 이해하는 데 도움이 됩니다.

2-5 RDB -- 구성 파일 자동 시작

<span style="display: block; background: url(https://my-wechat.mdnice.com/point.png); height: 30px; width: 100%; background-size: 40px; background-repeat: no-repeat; background-color: #272822; margin-bottom: -7px; border-radius: 5px; background-position: 10px 10px;"></span><code class="hljs" style="overflow-x: auto; padding: 16px; color: #ddd; display: -webkit-box; font-family: Operator Mono, Consolas, Monaco, Menlo, monospace; font-size: 12px; -webkit-overflow-scrolling: touch; letter-spacing: 0px; padding-top: 15px; background: #272822; border-radius: 5px;"><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">save</span> 900 1<br><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">save</span> 300 10<br><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">save</span> 60 10000<br><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">stop-writes-on-bgsave-error</span> <span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">yes</span><br></code>

로그인 후 복사

save [시간] [키 변경 횟수]

이 문서에서는 Redis 지속성의 전체 버전을 이해하는 데 도움이 됩니다. 즉, , 300초에 10개의 키 값이 있습니다. 변경이 발생하면 백그라운드에서 bgsave가 실행됩니다

3.AOF

3-1 AOF 개념

AOF 지속성: 각 쓰기 명령을 독립적인 로그에 기록하고, 다시 시작하면 AOF 파일의 명령이 다시 기록됩니다. -데이터 복구 목적을 달성하기 위해 실행됩니다. RDB와 비교하면 간단히 데이터 생성을 기록하는 과정이라고 설명할 수 있습니다

AOF의 주요 역할은 데이터 지속성의 실시간 특성을 해결하는 것입니다. 현재 Redis 지속성의 주류 방법입니다

3 -2 AOF 데이터 쓰기 프로세스

이 문서에서는 Redis 지속성의 전체 버전을 이해하는 데 도움이 됩니다. redis 명령 실행

redis의 AOF는 명령의 버퍼를 새로 고친 다음

특정 전략에 따라 redis.conf에 구성된 .aof 파일과 동기화합니다

3-3 AOF에 데이터를 쓰기 위한 세 가지 전략

항상: 각 쓰기 작업은 데이터 오류가 없고 성능이 낮은 AOF 파일에 동기화됩니다.
를 사용하지 않는 것이 좋습니다.
Everysec: 버퍼의 명령을 1초마다 AOF 파일에 동기화합니다. 이는 데이터 정확도와 성능이 더 높으며 권장되는 구성이기도 합니다.하지만 시스템이 갑자기 다운되면 1초 이내의 데이터는 유실됩니다
아니오: AOF 파일에 대한 각 동기화 주기는 운영 체제에서 제어하며 전체 프로세스는 제어할 수 없습니다

3-4 AOF 기능 활성화됨

구성: appendonly yes|noappendonly yes|no
作用：是否开启AOF持久化功能，默认为不开启状态
配置：appendfsync always| everysec | no
기능: AOF 지속성 기능을 켤지 여부, 기본값은 켜지지 않습니다
구성: appendfsync 항상|everysec | no
기능: AOF

Configuration: appenfilename filename

이 문서에서는 Redis 지속성의 전체 버전을 이해하는 데 도움이 됩니다. Function: AOF 영구 파일 이름, 기본 이름은appendonly.aof

🎜🎜🎜🎜 그런 다음 Redis 서비스를 다시 시작하면 usr/에서appendonly.aof 파일을 볼 수 있습니다. local/redis/data 디렉토리 🎜그런 다음 redis 클라이언트에서 명령을 실행하고 확인합니다. 데이터가appendonly.aof파일에 저장되는 것을 볼 수 있습니다. 🎜🎜

3-5 AOF 데이터 쓰기 문제

먼저 사례를 살펴보겠습니다. name 키를 반복적으로 설정한 후,appendonly.aof 파일을 열어보니 세 가지 작업이 있음을 알 수 있습니다. , 하지만 이 세 가지를 하나의 키로 각 작업을 수정합니다! 마지막 키만 저장할 수는 없나요? 이 질문으로 우리는 계속해서 이 문서에서는 Redis 지속성의 전체 버전을 이해하는 데 도움이 됩니다.

3-6 AOF rewriting

AOF에 명령이 계속해서 작성되면서 파일이 점점 더 커지게 됩니다. 이 문제를 해결하기 위해 redis는 AOF 재작성 메커니즘이 도입되어 파일 크기를 압축합니다. AOF 파일 재작성은 redis 프로세스의 데이터를 쓰기 명령으로 변환하고 이를 새 AOF 파일과 동기화하는 프로세스입니다. 간단히 말하면, 동일한 데이터에 대한 여러 명령의 실행 결과를 최종 결과 데이터에 해당하는 명령의 실행 기록으로 변환합니다.

예를 들어 위에서 set name 명령을 세 번 실행했지만 결국에는 마지막 실행의 데이터만 필요합니다. 즉, 마지막 실행 레코드만 필요합니다.

3-7 AOF 재작성 기능

디스크 사용량 감소 및 디스크 활용도 향상
지속성 효율성 향상, 지속성 쓰기 시간 감소, IO 성능 향상
데이터 복구 시간 감소, 개선 데이터 복구 효율성

3-8 AOF 다시 쓰기 규칙

프로세스에서 시간 초과된 데이터는 더 이상 파일에 기록되지 않습니다.
잘못된 지침을 무시하고 다시 쓰기 생성 시 처리 중인 데이터를 직접 사용하면 새 AOF 파일 값은 최종 데이터 기록 명령을 유지합니다. 예를 들어, del 명령어 . 키 값을 여러 번 설정하는 등의 작업을 수행합니다. <code style="overflow-wrap: break-word; margin: 0px 2px; font-family: " operator mono consolas monaco menlo monospace word-break: break-all color: rgb background: rgba padding: border-radius: height: line-height:>hdel，srem。多次设置一个key值等
对同一数据的多条写入命令合并为一条命令：如lpush list a lpush lsit b lpush list c可以转化为lpush list a b c🎜🎜🎜동일한 데이터에 대해 여러 쓰기 명령이 하나의 명령으로 병합됩니다: 예: lpush list a lpush lsit b lpush list c는 lpush 목록 a b c하지만 과도한 데이터 볼륨으로 인해 클라이언트 버퍼가 오버플로되는 것을 방지하기 위해 list，set，hash，zset类型每条指令最多写入64个元素

3-9 AOF手动重写

指令：bgrewriteaof

질문 3-5에 대해서는 명령줄에서 bgrewriteaof 명령을 실행한 후 Appendonly.aof 파일을 봅니다.

실행 후 , 우리는 파일이 더 작아지는 것을 발견할 것입니다. 파일에는 명령이 하나만 있습니다

3-10 AOF 수동 재작성이 작동하는 방식

3-11 AOF 자동 재작성

구성:auto-aof-rewrite-percentage 100 | auto-aof-rewrite-min-size 64mb触发对比参数：aof_current_size | aof_base_size

aof_current_size > auto-aof-rewrite-min-size 64mb가 다시 쓰기 시작되면

이 사진은 인터넷에서 가져온 것입니다

3-11 AOF 워크플로우 및 재작성 흐름 = 프로세스

이 문서에서는 Redis 지속성의 전체 버전을 이해하는 데 도움이 됩니다.

4 RDB와 AOF의 차이점

데이터에 매우 민감합니다. 기본 AOF 지속성 솔루션을 사용하는 것이 좋습니다.
- AOF 지속성 전략은 매초, 초당 fsync 시간을 사용합니다. • 이 전략 redis는 문제가 발생하면 0-1초 내의 데이터가 여전히 좋은 처리 성능을 유지할 수 있습니다.
- 참고: AO 파일의 저장 용량이 크고 복구 속도가 느리기 때문에
데이터 표시 단계 효율성으로 인해 RDB 지속성 솔루션을 사용하는 것이 좋습니다
- 데이터 수 단계를 잘 수행하십시오. 내부 손실이 없으며(이 단계는 개발자와 운영 및 유지 관리 담당자가 수동으로 유지 관리합니다), 단계 포인트 데이터 복구는 일반적으로 RDB 솔루션을 사용합니다
- 참고: 사용 긴밀한 데이터 지속성을 달성하기 위한 RDB는 Redis의 하락폭이 매우 낮습니다
종합적인 비교
- RDB와 AOF 사이의 선택은 실제로는 절충점이며 각각 장단점이 있습니다
- 몇 분 내에 데이터 손실을 감당할 수 없고 업계 데이터에 매우 민감한 경우 A0F를 선택하세요
- 몇 분 내에 데이터 손실을 견딜 수 있고 대용량 데이터 세트의 복구 속도를 추구할 수 있습니다. RDB
- 재해 복구에 RDB 사용
- 이중 보험 전략, 재시작 후 RDB와 AOF를 동시에 활성화합니다. Redis는 먼저 A0F를 사용하여 데이터를 복구하고 손실된 데이터의 양을 줄입니다.
❝
학습에 대한 끈기, 블로그에 대한 끈기, 공유에 대한 끈기는 Kaka가 경력을 쌓은 이래로 항상 고수해 온 신념입니다. Kaka의 기사가 거대한 인터넷에 도움이 될 수 있기를 바랍니다. 도움을 주셔서 감사합니다. 다음 호에서 만나요.