Redis의 두 가지 지속성 방법, 두 가지 지속성 방법이 필요한 이유는 무엇입니까?

Redis에는 두 가지 종류의 지속성(AOF 및 RDB)이 있습니다. 다음 기사에서는 이 두 가지 종류의 지속성을 이해하고 그 장점과 단점을 살펴보고 Redis에 두 가지 종류의 지속성이 필요한 이유를 소개할 것입니다. 모두에게 도움이 될 것입니다.

Redis의 두 가지 지속성 방법

우리 모두 알고 있듯이 Redis는 AOF와 RDB라는 두 가지 지속성 방법을 제공합니다.

RDB 지속성

• RDB 지속성, 은 현재 시점의 데이터베이스 상태를 디스크에 저장하는 것이며, 스냅샷 지속성이라고도 합니다.
• RDB는 서버 구성에 따라 수동으로 실행되거나 주기적으로 실행될 수 있습니다.
• RDB에서 생성된 파일은 압축된 바이너리 파일입니다. 이 파일을 통해 데이터베이스를 해당 시점의 상태로 복원할 수 있습니다.
Redis는 포그라운드 RDB 지속성 명령 SAVE와 백그라운드 RDB 지속성 명령 BGSAVE를 제공합니다. 포그라운드에서 실행하면 다른 Redis 명령이 차단됩니다. 백그라운드, Redis 클라이언트 명령 요청을 계속 처리할 수도 있습니다.
• SAVE和后台RDB持久化命令BGSAVE，前台执行时，Redis的其他命令会被阻塞，而后台执行时，Redis还可以继续处理客户端的命令请求。
• RDB二进制文件中，保存的是键值对数据，采用经过压缩的自定义编码，带校验。通过od命令可以转化为可读。
• 主从复制时，初始化的全量复制采用RDB文件。

【相关推荐：Redis视频教程】

AOF持久化

• AOF持久化，全称是Appen Only File，意思是追加的持久化方式，其中保存的是写命令，而非数据。
• AOF持久化过程分为命令追加、文件写入、文件同步三个步骤。
• 命令追加：Redis服务端每执行完一个写命令，都会以AOF协议格式将该写命令追加到服务器状态的aof_buf缓冲区末尾。
• 文件写入：Redis中，每结束一个事件循环之前，都会调用flushAppendOnlyFile函数，将aof_buf缓冲区中的内容写入到AOF文件。
• 文件同步：同步sync指的是文件写入到操作系统缓冲区中时，是否直接同步到磁盘中。通过配置，可以选择立即同步、每秒同步、不主动同步而由操作系统控制，这三种同步方式。关于文件I/O缓冲：https://www.litreily.top/2018/10/25/io-cache/
• Redis优先使用AOF文件来恢复数据。
• AOF文件由于存储命令，且没有经过压缩，其体积要大于RDB文件。
• AOF文件可以定期采用BGREWRITEAOF重写，减少重复命令、已失效命令，合并命令等。
• AOF文件支持后台重写，采用fork子进程的形式实现。子进程带有服务器进程的数据副本，再避免使用锁的情况下保证数据安全性。另外也采用AOF重写缓冲区解决了数据不一致。

两种持久化分别的优缺点

RDB的优点

• 文件体积小，适合拷贝做冷备

• 相比AOF，备份恢复速度更快

RDB的缺点

• 丢失数据多

• fork子进程来做BGSAVE，消耗一定的内存资源

AOF的优点

• 丢失数据少

• 增加了写缓冲区，无需寻址，速度快

• append-only，也无需做磁盘寻址，效率高

AOF的缺点

• 文件体积大

• AOF每次都需要做一下写入aof_bufRDB 바이너리 파일에는 검증을 통해 압축된 사용자 정의 인코딩을 사용하여 키-값 쌍 데이터가 저장됩니다. od 명령을 통해 읽을 수 있도록 변환할 수 있습니다.

마스터-슬레이브 복제 중에 초기화된 전체 복제는 RDB 파일을 사용합니다.

【관련 추천: Redis 동영상 튜토리얼

】

AOF persistence

• AOF persistence, 전체 이름은 Appen Only File , 이는 데이터 대신 쓰기 명령이 저장되는 추가 지속성 방법을 의미합니다.
• AOF 지속성 프로세스는 명령 추가, 파일 쓰기, 파일 동기화의 세 단계로 나뉩니다.
  명령 추가: Redis 서버가 쓰기 명령을 실행할 때마다 AOF 프로토콜 형식으로 서버 상태의 aof_buf 버퍼 끝에 쓰기 명령을 추가합니다.
• 파일 쓰기: Redis에서는 각 이벤트 루프가 끝나기 전에 flushAppendOnlyFile 함수가 호출되어 aof_buf 버퍼의 내용을 AOF 파일에 씁니다.
  파일 동기화: 동기화 sync는 파일이 운영 체제 버퍼에 기록될 때 디스크에 직접 동기화되는지 여부를 나타냅니다. 구성을 통해 즉시 동기화, 매초 동기화, 활성 동기화 없음(운영 체제에 의해 제어됨) 등 세 가지 동기화 방법을 선택할 수 있습니다. 파일 I/O 버퍼링 정보: https:// www.litreily.top/2018/10/25/io-cache/

• Redis는 우선적으로 AOF 파일을 사용하여 데이터를 복구합니다.

  🎜AOF 파일은 명령을 저장하고 압축되지 않기 때문에 RDB 파일보다 큽니다. 🎜🎜AOF 파일은 BGREWRITEAOF를 사용하여 정기적으로 다시 작성하여 중복 명령, 만료된 명령, 병합된 명령 등을 줄일 수 있습니다. 🎜🎜AOF 파일은 fork 하위 프로세스 형식으로 구현되는 백그라운드 재작성을 지원합니다. 하위 프로세스에는 서버 프로세스의 데이터 복사본이 있으므로 잠금을 사용하지 않고도 데이터 보안이 보장됩니다. 또한 AOF는 데이터 불일치를 해결하기 위해 버퍼를 다시 작성하는 데에도 사용됩니다. 🎜🎜

  🎜두 지속성 유형의 장단점🎜🎜

  🎜RDB의 장점🎜🎜🎜🎜🎜파일 크기가 작아서 콜드 백업용 복사에 적합🎜🎜🎜🎜AOF에 비해 백업 및 복구 속도가 빠릅니다🎜🎜🎜

  🎜RDB의 단점🎜🎜🎜🎜🎜손실 data🎜🎜🎜🎜fork 하위 프로세스는 BGSAVE를 수행하며, 이는 일정량의 메모리 리소스를 소비합니다🎜🎜🎜

  🎜AOF의 장점🎜🎜🎜 🎜🎜데이터 손실 없음🎜🎜🎜🎜쓰기 버퍼 증가, 주소 지정 필요 없음, 빠름🎜🎜🎜🎜추가 전용, 디스크 주소 지정 필요 없음, 고효율🎜🎜🎜

  🎜AOF의 단점🎜🎜🎜 🎜🎜파일 크기가 크다🎜🎜🎜🎜AOF는 매번 aof_buf를 작성해야 합니다. AOF 지속성을 켜면 QPS가 약간 줄어듭니다🎜🎜🎜🎜🎜 Redis에 두 가지 종류의 지속성 변경이 필요한 이유는 무엇입니까? 🎜🎜🎜위의 검토 후에 RDB와 AOF 지속성 사이에는 분명한 차이가 있음을 알 수 있습니다. 🎜🎜🎜🎜저장된 콘텐츠: RDB는 특정 시점의 데이터를 저장합니다. AOF는 실행된 쓰기 명령을 저장합니다. 🎜🎜🎜🎜파일 크기: RDB 파일은 더 작고 AOF 파일은 더 큽니다. 🎜🎜🎜🎜쓰기 방법: RDB는 포그라운드/백그라운드 쓰기 방법을 사용할 수 있으며, AOF는 쓰기 명령이 실행될 때마다 명령을 버퍼에 저장하는 방법을 사용하며 정기적으로 다시 쓸 수 있습니다. 🎜🎜🎜🎜데이터 손실: RDB는 가동 중지 시간과 마지막 RDB 동기화 사이의 모든 데이터를 잃습니다. AOF는 I/O 버퍼에 구성된 새로 고침 방법에 따라 1초 또는 몇 초 동안 데이터를 잃거나 잃지 않습니다. 🎜

이러한 비교를 바탕으로 마스터-슬레이브 복제 또는 전체 데이터 오프사이트 재해 복구 중에 RDB 지속성이 특정 시점의 데이터를 저장하고 다른 위치에 복사하는 데 더 적합하다는 것을 알 수 있습니다. 반면 AOF 지속성은 데이터 손실로 인해 비용이 더 많이 들지만 로컬 백업 및 Reids가 중단되고 다시 시작될 때 오류 복구로 더 적합합니다. 이것이 제가 Redis에 두 가지 지속성 방법이 필요한 이유를 이해한 것입니다.

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

위 내용은 Redis의 두 가지 지속성 방법, 두 가지 지속성 방법이 필요한 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!