Redis가 지속성 솔루션을 구현하는 방법(RDB 및 AOF에서 사용)

1. 지속성의 역할

1. 지속성이란 무엇입니까?

Redis의 모든 데이터는 메모리에 저장되며, 데이터 업데이트는 비동기적으로 하드 디스크에 저장됩니다.

2. 구현 방법

스냅샷: 특정 순간의 데이터 전체 백업 -mysql의 Dump -redis의 RDB 로그 쓰기: 모든 작업이 로그에 기록됩니다. 데이터를 복원하려면 로그를 다시 살펴보세요. -mysql의 Binlog - Hhase의 HLog -Redis의 AOF

2, RDB

1. RDB

2. 트리거 메커니즘 - 세 가지 주요 방법

첫 번째: 저장(동기화)

1 클라이언트가 저장 명령을 입력합니다---->redis 서버---->동기적으로 RDB 바이너리 파일을 생성합니다

2는 redis를 차단합니다(데이터 양이 매우 클 때)

3 파일 전략: if The 이전 RDB가 존재하며 이전 RDB를 대체합니다

4 복잡성 o(n)

두 번째 유형: bgsave(비동기, 백그로우드 저장 시작)

1 클라이언트가 save 명령을 입력합니다---->redis 서버-- -- 》비동기적으로 RDB 바이너리 파일 생성(fork 함수는 하위 프로세스 생성(fork는 reid 차단), createRDB 실행, 실행 성공, reids 메시지 반환)

2 이때 Redis에 액세스하면 클라이언트가 응답합니다. 일반적으로

3 파일 전략: 저장과 동일, 이전 RDB가 존재하는 경우 이전 RDB를 대체합니다.

4 복잡도 o(n)

세 번째 방법: (공통 방법) (******) 자동 (구성 파일을 통해)
구성 초 변경
save 900 1save 300 10save 60 1000060초에 1w개의 데이터가 변경되면 rdb가 자동 생성됩니다
300초에 10개의 데이터가 변경되면 rdb가 자동 생성됩니다
데이터가 900초에 변경되면 rdb가 자동 생성됩니다 b

위 세 가지 조건 중 하나라도 충족되면 RDB가 자동 생성되고 내부적으로 bgsave가 사용됩니다

#Configuration:

save 900 1 #Configure one

save 300 10 #하나 구성

save 60 10000 #하나 구성

dbfilename dump .rdb #rdb 파일의 이름, 기본값은 dump.rdb

dir ./ #rdb 파일이 현재 디렉터리에 존재합니다

stop-writes-on-bgsave-error yes #bgsave에서 오류가 발생하면 쓰기 중지 여부는 기본값은 yes

rdbcompression yes #압축 형식 사용

rdbchecksum yes #rdb 파일 체크섬 여부

#Best configuration

save 900 1

save 300 10

save 60 10000 dbfilename dump-$ { port}.rdb

#포트번호를 파일명으로 사용하세요.

dir /bigdiskpath # 저장 경로를 큰 하드 디스크 위치 디렉터리에 넣습니다

stop-writes-on-bgsave -error yes

#오류 발생 시 중지

rdbcompression yes #Compression

rdbchecksum yes #Verification

RDB 트리거 메커니즘은 일반적으로 세 번째 방법을 사용하지만 이 방법에도 단점이 있습니다. 수정된 항목 개수가 설정 범위를 벗어나면 실행되지 않아 많은 데이터가 유지되지 않게 됩니다. 그래서 우리는 일반적으로 다음과 같은 방법을 사용합니다: AOF.

중요하지 않은 데이터를 저장하고 싶다면 RDB(예: 캐시 데이터)를 사용하면 됩니다. 매우 중요한 데이터를 저장하려면 AOF를 사용하는 것이 좋지만 두 가지 방법을 동시에 사용할 수도 있습니다.

3.AOF

1.RDB 문제

시간과 성능이 많이 소모됩니다. 통제할 수 없으므로 데이터가 손실될 수 있습니다.

2. AOF 소개

클라이언트가 명령을 작성할 때마다 로그가 기록되어 로그 파일에 저장됩니다. 다운타임이 발생하면 데이터를 완전히 복원할 수 있습니다.

3.세 가지 전략. of AOF

로그는 하드 디스크에 직접 기록되지 않고 먼저 버퍼에 저장됩니다. 버퍼는 일부 전략에 따라 하드 디스크에 기록됩니다

#첫 번째 유형: Always: redis--》Buffer Refreshed 명령을 작성하여--->Every Command fsync를 하드 디스크에 --->AOF 파일

#두 번째 유형:everysec(기본값): redis--->명령으로 새로 고친 버퍼 쓰기--->버퍼를 Fsync 1초마다 하드 디스크에--》AOF 파일

#세 번째 유형: no:redis------》명령으로 새로 고쳐진 버퍼 쓰기---》운영 체제가 결정하고, 버퍼는 하드 디스크에 fsync됩니다.--》 AOF 파일

command	always	everysec	no
장점	데이터 손실 없음	fsync는 1초에 한 번, 1초의 데이터가 손실됩니다	하지 마세요 걱정하지 마세요
단점	IO 오버헤드가 크고 일반 SATA 디스크의 TPS는 수백 TPS에 불과합니다.	1초의 데이터 손실	제어 불가능

4.

다음과 같이 명령이 점차 작성되면서 동시성 볼륨이 증가함에 따라 AOF 파일이 점점 커지게 됩니다. 이 문제는 AOF rewriting

native AOF	AOF rewriting
set hello로 해결할 수 있습니다. world 안녕 java 설정 안녕 설정 ㅋㅋㅋ incr counter ncr counter rpush mylist a rpush mylist b rpush mylist c 데이터 만료	안녕하세요 설정하세요 헤헤 카운터 2 설정 rpush mylist a b c

핵심은 만료되고, 쓸모없고, 반복되고, 최적화 가능한 명령을 최적화하여 디스크 사용량을 줄이고 복구 속도를 높일 수 있습니다

구현 방법

bgrewriteaof : 클라이언트에서 서비스로 bgrewriteaof 명령을 서버에 보내면 서버는 AOF rewrite

AOF rewrite 구성을 완료하기 위해 포크 프로세스를 시작합니다.

rewrite process

AOF 구성 파일(**** **)

appendonly yes # 이 옵션을 yes로 설정하고, appendonly-${port}.aof"를 엽니다. #저장된 파일 이름appendfsynceverysec #두 번째 전략 채택 dir /bigdiskpath #저장 경로 no-appendfsync -on-rewrite yes # aof를 다시 쓸 때 aof의 추가 작업을 수행해야 합니까? aof를 다시 쓰면 성능과 디스크가 소모됩니다. 일반적인 aof 디스크 쓰기에는 특정 충돌이 발생합니다

4. RDB와 AOF 선택

1. rdb와 aof

비교 시작 우선순위낮음 높음(전화를 끊고 다시 시작하면 Aof 데이터가 로드됨) SizeSmall Large복구 속도 FastSlow데이터 보안 데이터 손실 전략적 결정에 따름 심각 무거움 Light

2.rdb 최고의 전략

rdb 꺼짐, 마스터-슬레이브 작동
중앙 집중식 관리: 일별, 시간별 백업 데이터
마스터-슬레이브 구성, 슬레이브 노드 켜짐

3.aof 최고의 전략

en: 캐시 및 스토리지는 대부분 켜져 있음
aof 재작성 중앙 집중식 관리
everysec: 매초마다 새로 고치는 전략을 통해

4. 최상의 전략

소형 샤딩: 각 Redis의 최대 메모리는 4g
캐시 또는 스토리지: 특성에 따라 다양한 전략을 사용하세요
하드 디스크, 메모리, 네트워크 로드 등을 항상 모니터링하세요
메모리가 충분해야 합니다

위는 Redis(4) - Persistence 솔루션(RDB 및 RDB에서 사용)의 전체 내용입니다. AOF).

관련 참조: PHP 중국어 웹사이트

command	rdb	aof

위 내용은 Redis가 지속성 솔루션을 구현하는 방법(RDB 및 AOF에서 사용)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!