Redis의 고가용성 및 지속성에 대한 자세한 설명

이 글에서는 Redis의 고가용성과 지속성에 대해 설명하고, Redis의 지속성 기능과 두 가지 방법(RDB 및 AOF)에 대해 살펴보겠습니다.

1. Redis 고가용성

1. Redis 고가용성 개요

  웹 서버에서 고가용성은 서버에 정상적으로 접속할 수 있는 시간을 말하며, 측정 기준은 얼마나 오랫동안 정상적인 서비스를 제공할 수 있는지를 의미합니다( 99.9%, 99.99%, 99.999% 등). [관련 권장사항: Redis 동영상 튜토리얼]

  그러나 Redis의 맥락에서 고가용성의 의미는 일반적인 서비스(마스터-슬레이브 분리, 빠른 재해 복구 등) 제공을 보장하는 것보다 더 넓은 의미로 보입니다. 기술), 데이터 용량 확장도 고려해야 하며, 데이터 보안이 손실되지 않는 등의 문제가 있습니다.

2. Redis 고가용성 전략

Redis에서 고가용성을 달성하기 위한 기술에는 주로 지속성, 마스터-슬레이브 분리, 센티널 및 클러스터가 포함됩니다.

고가용성 전략	설명
Persistence	Persistence은 가장 간단한 고가용성 방법입니다(때때로 고가용성 방법으로 분류되지도 않음). 주요 기능은 데이터 백업입니다. 곧 데이터가 저장됩니다. 프로세스가 종료될 때 데이터가 손실되지 않도록 하드 디스크에 저장합니다.
마스터-슬레이브 복제	마스터-슬레이브 복제는 고가용성 Redis의 기반입니다. Sentinel과 Cluster 모두 마스터-슬레이브 복제를 기반으로 고가용성을 달성합니다. 마스터-슬레이브 복제는 주로 데이터의 다중 시스템 백업은 물론 읽기 작업을 위한 로드 밸런싱 및 간단한 오류 복구를 구현합니다. 결함: 장애 복구를 자동화할 수 없고, 쓰기 작업의 로드 밸런싱을 수행할 수 없으며, 저장 용량이 단일 시스템으로 제한됩니다.
Sentinel	Sentinel은 마스터-슬레이브 복제를 기반으로 자동화된 오류 복구를 구현합니다. 단점: 쓰기 작업은 로드 밸런싱될 수 없으며 저장 용량은 단일 시스템으로 제한됩니다.
Cluster	Redis는 쓰기 작업의 로드 밸런싱이 불가능하고 저장 용량이 단일 머신으로 제한되는 문제를 클러스터링을 통해 해결하여 비교적 완전한 고가용성 솔루션을 구현합니다.

2. Redis 지속성

1. Redis 지속성 기능

  Redis는 메모리 내 데이터베이스로, 서버 정전 등으로 인해 Redis 프로세스가 비정상적으로 종료된 후 데이터가 영구적으로 손실되는 것을 방지합니다. 따라서 정기적인 유지 관리가 필요합니다. Redis가 다음에 다시 시작될 때 메모리에서 하드 디스크로 데이터를 저장해야 합니다. 영구 파일을 사용하여 데이터를 복구하세요. 또한 재해 백업 목적으로 영구 파일을 원격 위치에 복사할 수 있습니다.

2. Redis 지속성의 두 가지 방법

• RDB 지속성
  메모리에 있는 Redis의 데이터베이스 기록을 정기적으로 디스크에 저장하는 것이 원칙입니다.
• AOF 지속성(파일만 추가)
  MySQL의 binlog와 유사한 방식으로 Redis 작업 로그를 파일에 기록하는 것이 원칙입니다.
  AOF 지속성은 실시간 성능이 더 뛰어나므로, 즉 프로세스가 예기치 않게 종료될 때 데이터 손실이 적으므로 AOF가 현재 주류 지속성 방법이지만 RDB 지속성은 여전히 ​​그 자리를 차지하고 있습니다.

3.RDB 지속성

 RDB 지속성은 바이너리 압축을 이용하여 현재 프로세스의 데이터를 메모리에 스냅샷으로 생성하여 지정된 시간 간격 내에 하드디스크에 저장하는 것을 말합니다(그래서 스냅샷 지속성이라고도 합니다). 저장 및 저장 파일 접미사는 ​​rdb이며 Redis가 다시 시작되면 스냅샷 파일을 읽어 데이터를 복원할 수 있습니다.

3.1 트리거 조건

RDB 지속성 트리거는 수동 트리거와 자동 트리거의 두 가지 유형으로 나뉩니다.

3.1.1

• save 명령과 bgsave 명령을 모두 수동으로 트리거하면 RDB 파일을 생성할 수 있습니다.
• save 명령은 RDB 파일이 생성될 때까지 Redis 서버 프로세스를 차단합니다. Redis 서버가 차단되는 동안 서버는 명령 요청을 처리할 수 없습니다.
• bgsave 명령은 하위 프로세스를 분기(fork)합니다. 하위 프로세스는 RDB 파일 생성을 담당하며 상위 프로세스(예: Redis 기본 프로세스)는 계속해서 요청을 처리합니다.
• bgsave 명령 실행 중에는 fork 하위 프로세스만 서버를 차단하고, save 명령의 경우 전체 프로세스가 서버를 차단하므로 save는 기본적으로 중단되었으며 save 사용은 제거되어야 합니다. 온라인 환경에서.

3.1.2 자동 트리거

• RDB 지속성이 자동으로 트리거되면 Redis는 지속성을 위해 save 대신 bgsave를 선택합니다.

3.2 구성 방법

• 구성 파일을 수정하여 설정: save m n
• 자동 트리거의 가장 일반적인 상황은 구성 파일에서 save m n을 전달하는 것입니다. m초 내에 n 변경 사항이 발생하면 bgsave는 다음과 같이 지정됩니다. 트리거되었습니다.

[root@localhost ~]# vim /etc/redis/6379.conf ##219行，以下三个save条件满足任意一个时，都会引起bgsave的调用save 900 1	##当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsavesave 300 10	##当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsavesave 60 10000	##当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave##254行，指定RDB文件名dbfilename dump.rdb##264行，指定RDB文件和AOF文件所在目录dir /var/lib/redis/6379##242行，是否开启RDB文件压缩rdbcompression yes

3.3 기타 자동 트리거 메커니즘

mn 저장 외에도 bgsave를 트리거하는 몇 가지 다른 상황이 있습니다.

• 마스터-슬레이브 복제 시나리오에서 슬레이브 노드가 전체 복사 작업을 수행하면 마스터 노드는 bgsave 명령을 실행하고 rdb 파일을 슬레이브 노드로 보냅니다.
• shutdown 명령을 실행하면 RDB 지속성이 자동으로 수행됩니다.

3.4 실행 프로세스

• Redis 상위 프로세스는 먼저 현재 save를 실행 중인지 bgsave/bgrewriteaof의 하위 프로세스인지 확인합니다. 실행 중이면 bgsave 명령이 직접 반환됩니다. bgsave/bgrewriteaof의 하위 프로세스는 주로 성능 고려 사항으로 인해 동시에 실행할 수 없습니다. 두 개의 동시 하위 프로세스가 동시에 많은 수의 디스크 쓰기 작업을 수행하므로 심각한 성능 문제가 발생할 수 있습니다.
• 상위 프로세스는 하위 프로세스를 생성하기 위해 포크 작업을 수행합니다. 이 프로세스 중에 상위 프로세스는 차단되고 Redis는 클라이언트에서 어떤 명령도 실행할 수 없습니다.
• 상위 프로세스가 포크된 후 bgsave 명령은 "백그라운드 저장 시작" 메시지를 반환하고 더 이상 상위 프로세스를 차단하지 않으며 다른 명령에 응답할 수 있습니다.
• 하위 프로세스는 RDB 파일을 생성하고 기반으로 임시 스냅샷 파일을 생성합니다. 완료 후 원본 프로세스가 저장됩니다. 원자 교체를 위한 파일이 있습니다
• 자식 프로세스는 완료를 알리는 신호를 부모 프로세스에 보내고, 상위 프로세스는 통계 정보를 업데이트합니다

3.5 시작 시 로딩

  RDB 파일 로딩은 서버 시작 시 자동으로 수행되며, 별도의 Order는 없습니다. 그러나 AOF의 우선순위가 높기 때문에 AOF가 켜져 있으면 Redis는 데이터를 복원하기 위해 AOF 파일을 로드하는 데 우선순위를 부여합니다. AOF가 꺼진 경우에만 Redis 서버가 시작되고 자동으로 로드될 때 RDB 파일이 감지됩니다. 로드가 완료될 때까지 RDB 파일을 로드하는 동안 서버가 차단됩니다.
 Redis는 RDB 파일을 로드할 때 RDB 파일을 확인합니다. 파일이 손상되면 로그에 오류가 인쇄되고 Redis가 시작되지 않습니다.

4. AOF 지속성

  RDB 지속성은 프로세스 데이터를 파일에 기록하는 반면, AOF 지속성은 Redis가 실행한 각 쓰기 및 삭제 명령을 별도의 로그 파일에 기록하며, 쿼리 작업은 Redis가 다시 시작될 때 기록되지 않습니다. AOF 파일을 다시 복원하여 데이터를 복원합니다.
 RDB에 비해 AOF는 실시간 성능이 더 뛰어나므로 주류 지속성 솔루션이 되었습니다.

4.1 AOF 켜기

Redis 서버는 기본적으로 RDB를 켜고 AOF를 끕니다. AOF를 켜려면 구성 파일에서 구성해야 합니다.

[root@localhost ~]# vim /etc/redis/6379.conf ##700行，修改，开启AOFappendonly yes##704行，指定AOF文件名称appendfilename "appendonly.aof"##796行，是否忽略最后一条可能存在问题的指令aof-load-truncated yes[root@localhost ~]# /etc/init.d/redis_6379 restartStopping ...
Redis stopped
Starting Redis server...

4.2 실행 프로세스

Redis의 모든 쓰기 명령은 기록되기 때문에 AOF를 실행할 필요는 없습니다. 다음은 AOF의 실행 과정을 설명합니다.

AOF 실행 프로세스에는 다음이 포함됩니다.

• 명령 추가(append): Redis write 명령을 버퍼 aof_buf에 추가합니다.
• 파일 쓰기(쓰기) 및 파일 동기화(동기화): 다양한 동기화 전략에 따라 aof_buf의 콘텐츠를 하드 디스크에 동기화합니다. 다시 쓰기(다시 쓰기): AOF 파일을 정기적으로 다시 작성하여 압축합니다.
• 4.2.1 명령 추가(append)

Redis는 명령을 파일에 직접 쓰는 대신 먼저 버퍼에 추가합니다. 이는 주로 쓰기 명령이 있을 때마다 하드 디스크에 직접 명령을 쓰는 것을 피하기 위한 것입니다. , 하드 디스크 IO를 Redis 로드 병목 현상이라고 합니다.

명령 추가 형식은 Redis 명령에서 요청한 프로토콜 형식이며 일반 텍스트 형식이며 우수한 호환성, 강력한 가독성, 쉬운 처리, 간단한 작동 및 2차 오버헤드 방지라는 장점이 있습니다. AOF 파일에는 Redis에서 추가한 데이터베이스를 지정하는 데 사용되는 select 명령(예: 0번 데이터베이스를 선택하려면 select 0)을 제외하고 나머지는 클라이언트에서 보낸 쓰기 명령입니다.

4.2.2 파일 쓰기(쓰기) 및 파일 동기화(동기화)

Redis는 AOF 버퍼 영역에 대한 다양한 동기화 파일 전략을 제공하며 해당 전략에는 운영 체제의 쓰기 및 fsync 기능이 포함됩니다. :

파일 쓰기 효율성을 높이기 위해 최신 운영 체제에서는 사용자가 파일에 데이터를 쓰기 위해 쓰기 함수를 호출할 때 일반적으로 버퍼가 가득 차거나 이를 초과하면 운영 체제에서 데이터를 임시로 저장합니다. 지정된 시간 제한이 있어야만 버퍼의 데이터가 실제로 하드 디스크에 기록됩니다. 이러한 작업은 효율성을 향상시키지만 보안 문제도 발생합니다. 컴퓨터가 종료되면 메모리 버퍼의 데이터가 손실되므로 시스템은 운영 체제를 강제로 작동시킬 수 있는 fsync 및 fdatasync와 같은 동기화 기능도 제공합니다. 버퍼에 있는 데이터를 즉시 전송합니다. 데이터 보안을 보장하기 위해 데이터는 하드 디스크에 기록됩니다.

4.2.3 세 가지 동기화 방법

AOF 캐시 영역의 동기화 파일 전략에는 세 가지 동기화 방법이 있으며 /etc/redis/6379.conf의 729번 라인을 수정하여 구성합니다.

4.2.3.1appendfsync Always

이 명령은 aof_buf에 쓴 후 시스템 fsync 작업을 즉시 호출하여 AOF 파일에 동기화합니다. fsync가 완료된 후 스레드가 반환됩니다. 이 경우 모든 쓰기 명령은 AOF 파일에 동기화되어야 하며 하드 디스크 IO는 성능 병목 현상이 발생합니다. Redis는 약 수백 개의 TPS 쓰기만 지원할 수 있으므로 SSD를 사용해도 Redis의 성능이 심각하게 저하됩니다. SSD), 초당 수만 개의 명령만 처리할 수 있어 SSD의 수명이 크게 단축됩니다.

4.2.3.2appendfsync no

이 명령은 aof_buf에 쓴 후 시스템 쓰기 작업을 호출하고 AOF 파일에 대해 fsync 동기화를 수행하지 않습니다. 동기화는 운영 체제에 의해 로드되며 동기화 기간은 일반적으로 30초입니다. 이 경우 파일 동기화 시간을 제어할 수 없으며, 버퍼에 많은 양의 데이터가 축적되어 데이터 보안을 보장할 수 없습니다.

4.2.3.3appendfsynceverysec(권장)

쓰기가 완료된 후 스레드가 반환됩니다. fsync 동기화 파일 작업은 전용 스레드에 의해 초당 한 번씩 호출됩니다. Everysec은 앞서 언급한 두 가지 전략, 즉 성능과 데이터 보안 간의 균형을 절충한 것입니다. 이는 Redis의 기본 구성이자 권장되는 구성입니다.

4.2.4 파일 재작성(rewrite)

시간이 지남에 따라 Redis 서버는 점점 더 많은 쓰기 명령을 실행하고 AOF 파일은 점점 더 커질 것입니다. 너무 큰 AOF 파일은 정상적인 작동에 영향을 미칠 뿐만 아니라 서버를 사용하면 데이터 복구에 너무 오랜 시간이 걸립니다.

파일 다시 쓰기는 AOF 파일 크기를 줄이기 위해 AOF 파일을 정기적으로 다시 쓰는 것을 의미합니다. AOF 재작성은 Redis 프로세스의 데이터를 쓰기 명령으로 변환하고 이를 새 AOF 파일과 동기화한다는 점에 유의해야 합니다. 이전 AOF 파일에서는 읽기 또는 쓰기 작업이 수행되지 않습니다.

파일 재작성에 대한 또 다른 주의 사항은 다음과 같습니다. AOF 지속성의 경우 파일 재작성을 적극 권장하지만 반드시 그럴 필요는 없습니다. Redis에서 데이터를 지속하고 시작할 수 있으므로 실제로는 자동 파일 재작성이 가능합니다. 꺼지고 매일 특정 시간에 정기적으로 예약된 작업이 실행됩니다.

4.2.4.1 압축 기능이 있는 이유

File Rewrite가 AOF 파일을 압축할 수 있는 이유는 다음과 같습니다.

만료된 데이터는 더 이상 파일에 기록되지 않습니다.

• 일부 데이터가 반복적으로 설정되거나(set mykey v1, set mykey v2) 일부 데이터가 삭제되거나(set myset v1, del myset) 잘못된 명령이 더 이상 파일에 기록되지 않습니다.
• 여러 명령을 하나로 병합할 수 있습니다. 예를 들어 sadd myset v1, sadd myset v2, sadd myset v3을 sadd myset v1 v2 v3에 병합할 수 있습니다.
• 위의 이유에서 볼 수 있듯이 AOF는 다시 쓴 후 더 적은 수의 명령을 실행하므로 파일을 다시 쓰면 파일이 차지하는 공간을 줄일 수 있을 뿐만 아니라 복구 속도도 높일 수 있습니다.

4.2.4.2 파일 재작성 트리거

파일 재작성은 수동 트리거와 자동 트리거로 구분됩니다.

• 수동 트리거: bfrewriteaof 명령을 직접 호출합니다. 이 명령의 실행은 bgsave와 다소 유사합니다. 두 포크 프로세스는 모두 특정 작업을 수행하며 포크할 때만 차단됩니다.
• 자동 트리거링: auto-aof-rewrite-min-size 옵션과 auto-aof-rewrite-percentage 옵션을 설정하여 bgrewriteaof를 자동으로 실행합니다. auto-aof-rewrite-min-size와 auto-aof-rewrite-percentage 두 가지 옵션이 동시에 충족되는 경우에만 AOF 다시 쓰기, 즉 bgrewriteaof 작업이 자동으로 트리거됩니다.

자동으로 트리거된 구성은 /etc/redis/6379.conf의 771 및 772행에 있습니다.自动触发的配置位于/etc/redis/6379.conf的771行和772行

• auto-aof-rewrite-percentage 100
  当前AOF文件大小（即aof_current_size）是上次日志重写时AOF文件大小（aof_base_size）两倍时，发生bgrewriteaof操作
• auto-aof-rewrite-min-size 64mb
  当前AOF文件执行bgrewriteaof命令的最小值，避免刚开始启动Redis时由于文件尺寸较小导致频繁的bgrewriteaof

4.2.4.3 文件重写的流程

文件重写的流程如下：

• Redis父进程首先平判断当前是否存在正在执行bgsave/bgrewriteaof的子进程；如果存在则bgrewriteaof命令直接返回，如果存在bgsave命令则等bgsave执行完成后再执行。
• 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的。
• 父进程fork后，bgrewriteaof命令返回“Background append only file rewrite started”信息并不再阻塞父进程，并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有AOF机制的正确。
• 由于fork操作使用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然在响应命令，因此Redis使用AOF重写缓冲区（aof_rewrite_buf）保存这部分数据，防止新AOF文件生成期间丢失这部分数据。也就是说，bgrewriteaof执行期间，Redis的写命令同时追加到aof_buf和aof_rewrite_buf两个缓冲区。
• 子进程根据内存快照，按照命令合并规则写入到新的AOF文件。
• 子进程写完新的AOF文件后，向父进程发信号，父进程更新统计信息，具体可以通过info persistence查看。
• 父进程把AOF重写缓冲区的数据写入到新的AOF文件，这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。
• 使用新的AOF文件替换老文件，文成AOF重写。

关于文件重写的流程，有两点需要特别注意：

auto-aof-rewrite-percentage 100
• 현재 AOF 파일 크기(예: aof_current_size) )는 마지막 로그 재작성 중에 AOF 파일 크기(aof_base_size)가 두 배로 증가했을 때 bgrewriteaof 작업이 발생했습니다.
• auto-aof-rewrite-min-size 64mb
방지하기 위해 현재 AOF 파일에서 bgrewriteaof 명령을 실행하기 위한 최소값입니다. Redis를 시작할 때 파일 오류가 발생합니다. 크기가 작으면 bgrewriteaof

4.2.4.3 파일 다시 쓰기 프로세스

파일 다시 쓰기 프로세스는 다음과 같습니다.
• Redis 상위 프로세스는 먼저 현재 bgsave/bgrewriteaof를 실행하는 하위 프로세스가 있는지 확인합니다. 존재하는 경우 bgrewriteaof 명령이 직접 반환됩니다. bgsave 명령이 있는 경우 bgsave 실행이 완료된 후 실행됩니다.
• 상위 프로세스는 하위 프로세스를 생성하기 위해 포크 작업을 수행합니다. 이 프로세스 동안 상위 프로세스는 차단됩니다.

상위 프로세스가 분기된 후 bgrewriteaof 명령은 "백그라운드 추가 전용 파일 다시 쓰기 시작됨" 메시지를 반환하고 더 이상 상위 프로세스를 차단하지 않으며 다른 명령에 응답할 수 있습니다. 모든 Redis 쓰기 명령은 여전히 ​​AOF 버퍼에 기록되고 원래 AOF 메커니즘의 정확성을 보장하기 위해appendfsync 정책에 따라 하드 디스크에 동기화됩니다.

포크 작업은 쓰기 중 복사 기술을 사용하므로 하위 프로세스는 포크 작업 중에만 메모리 데이터를 공유할 수 있습니다. 상위 프로세스가 여전히 명령에 응답하고 있으므로 Redis는 AOF 재작성 버퍼(aof_rewrite_buf)를 사용하여 데이터의 이 부분을 저장하여 새 AOF 파일 생성 중에 이 데이터 부분이 손실되는 것을 방지합니다. 즉, bgrewriteaof 실행 중에 Redis의 쓰기 명령이 aof_buf 및 aof_rewrite_buf 버퍼에 동시에 추가됩니다.

하위 프로세스는 메모리 스냅샷과 명령 병합 규칙에 따라 새 AOF 파일에 씁니다.

하위 프로세스가 새 AOF 파일 작성을 마친 후 상위 프로세스에 신호를 보내고 상위 프로세스는 정보 지속성을 통해 볼 수 있는 통계 정보를 업데이트합니다.

상위 프로세스는 AOF 재작성 버퍼의 데이터를 새 AOF 파일에 기록하여 새 AOF 파일에 저장된 데이터베이스 상태가 서버의 현재 상태와 일치하는지 확인합니다.

이전 파일을 새 AOF 파일로 교체하고 AOF에 다시 작성하세요.

파일 재작성 프로세스와 관련하여 특별한 주의가 필요한 두 가지 사항이 있습니다:

재작성은 하위 프로세스를 분기하는 상위 프로세스에 의해 수행됩니다.

재작성 중에 Redis가 실행하는 쓰기 명령 Redis는 새 AOF 파일에 이 목적을 위해 aof_rewrite_buf 캐시를 도입합니다

🎜4.3 시작 시 로드🎜🎜🎜AOF가 켜져 있으면 Redis는 시작 시 데이터를 복원하기 위해 먼저 AOF 파일을 로드합니다. AOF가 꺼진 경우에만 로드되어 데이터를 복구할 수 있습니다. 🎜🎜AOF를 켰지만 AOF 파일이 없으면 RDB 파일이 있어도 로드되지 않습니다. 🎜🎜Redis는 AOF 파일을 로드할 때 AOF 파일을 확인합니다. 파일이 손상되면 로그에 오류가 인쇄되고 Redis가 시작되지 않습니다. 그러나 AOF 파일의 끝이 불완전하고(갑자기 시스템 가동 중지로 인해 파일 끝이 쉽게 불완전해질 수 있음) aof_load_truncated 매개변수가 설정된 경우 로그에 경고가 출력되고 Redis는 이를 무시합니다. AOF 파일의 끝을 확인하고 성공적으로 시작합니다. aof_load_truncated 매개변수는 기본적으로 활성화됩니다. 🎜🎜🎜5. RDB와 AOF의 장점과 단점🎜🎜🎜RDB 지속성🎜🎜🎜장점: RDB 파일은 크기가 작고 네트워크 전송 속도가 빠르며 전체 복사에 적합합니다. 물론, RDB의 가장 중요한 장점 중 하나는 AOF에 비해 성능에 미치는 영향이 상대적으로 적다는 것입니다. 🎜 단점: RDB 파일의 잘 알려진 단점은 데이터 스냅샷의 지속성 방법에 따라 실시간 지속성을 달성할 수 없다는 것입니다. 오늘날 데이터가 점점 더 중요해지면서 대량의 데이터 손실은 종종 용납될 수 없습니다. 그래서 AOF 지속성이 주류가 됩니다. 또한 RDB 파일은 특정 형식을 충족해야 하며 호환성이 좋지 않아야 합니다(예: 이전 버전의 Redis는 새 버전의 RDB 파일과 호환되지 않습니다). 🎜 RDB 지속성을 위해 bgsave가 포크 작업을 수행할 때 Redis 기본 프로세스가 차단되는 반면, 하드 디스크에 데이터를 쓰는 하위 프로세스도 IO 부담을 가져옵니다. 🎜🎜🎜AOF 지속성🎜🎜🎜 RDB 지속성에 이어 AOF의 우선 순위는 2단계 지속성과 우수한 호환성을 지원하는 것입니다. 단점은 대용량 파일, 느린 복구 속도 및 성능에 큰 영향을 미칩니다. 🎜🎜AOF 지속성의 경우 하드 디스크에 데이터를 쓰는 빈도가 크게 증가하고(everysec 정책에 따라 두 번째 수준) IO 압력이 더 커지며 AOF에 추가 차단 문제가 발생할 수도 있습니다. 🎜🎜AOF 파일 재작성은 RDB의 bgsave와 유사하며 하위 프로세스에 대한 포크 및 IO 압력 중 차단 문제가 있습니다. 상대적으로 말하면 AOF는 하드 디스크에 데이터를 더 자주 쓰기 때문에 Redis 기본 프로세스의 성능에 더 큰 영향을 미칩니다. 🎜

일반적으로 AOF의 자동 다시 쓰기 기능을 끄고 다시 쓰기 작업에 대한 예약된 작업을 설정하고 업무량이 적은 이른 아침에 수행하여 AOF가 시스템에 미치는 영향을 줄이는 것이 좋습니다. 메인 프로세스의 성능과 IO의 읽기 및 쓰기 압력.

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

위 내용은 Redis의 고가용성 및 지속성에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!