Redis의 지속성 메커니즘에 대해 이야기해 보겠습니다. RDB를 사용해야 할까요? 아니면 AOF를 사용해야 할까요?

이 기사에서는 Redis(RDB 및 AOF)의 지속성 메커니즘을 이해하고 RDB를 사용할지 AOF를 사용할지에 대해 설명합니다. 모두에게 도움이 되기를 바랍니다!

RDB

1. RDB란

RDB: 가끔씩 메모리에 있는 데이터를 스냅샷으로 디스크의 임시 파일에 기록하고, 스냅샷 파일을 읽어서 디스크에 저장합니다. 복구 중 메모리. 충돌이 발생하고 다시 시작되면 메모리의 데이터는 확실히 사라지고 Redis를 다시 시작한 후에 복원됩니다. [관련 권장사항: Redis 동영상 튜토리얼]

2. 백업 및 복구

메모리 백업-->디스크 임시 파일--> RDB의 장점과 단점

장점

가끔씩 백업, 전체 백업

• • 간단한 재해 복구, 원격으로 전송 가능

  • 하위 프로세스가 백업되면 기본 프로세스에는 IO 작업이 없습니다. (쓰기 수정 없음) 또는 삭제)를 수행하여 백업 데이터의 무결성을 보장합니다

  • AOF에 비해 대용량 파일이 있는 경우 빠르게 다시 시작하고 복원할 수 있습니다

  • 단점
In 실패할 경우 마지막 파일이 손실될 수 있습니다. 백업 데이터

• • 하위 프로세스가 차지하는 메모리는 상위 프로세스와 정확히 동일하므로 CPU 부담이 발생합니다

  • 예약된 전체 백업은 무겁기 때문에 경우 실시간 백업을 처리할 수 없습니다.

  4. RDB 구성

redis.conf에서 저장 위치를 ​​맞춤 설정할 수 있습니다:

/user/local/redis/working/dump.rdb

• 
  저장 메커니즘:

• save 900 1
  save 300 10
  save 60 10000
  save 10 3

  * 如果1个缓存更新，则15分钟后备份
  * 如果10个缓存更新，则5分钟后备份
  * 如果10000个缓存更新，则1分钟后备份

stop-writes-on-bgsave-error

• yes: 저장 과정에서 오류가 발생하면 쓰기 작업을 중지하세요.
  no: 데이터 불일치가 발생할 수 있습니다
  • rdbcompression
• yes: RDB 압축 모드 켜기
  no: 닫으면 CPU 소비가 절약되지만 파일이 커집니다. nginx와 같은 이유
  • rdbchecksum
• yes: CRC64 알고리즘 확인을 사용하여 rdb에서 데이터 확인을 수행합니다. , 10% 성능 손실
  아니요: 검증 없음
  요약

RDB는 대용량 데이터 복구에 적합하지만 데이터의 무결성과 일관성이 부족할 수 있습니다. AOF

AOF 기능

사용자가 요청한 쓰기 작업을 로그 형식으로 기록합니다. 쓰기 작업만 저장되므로 읽기 작업은 기록되지 않습니다.

• 파일이 수정되지 않고 추가됩니다.

• Redis의 aof Recovery는 실제로 첨부된 파일을 처음부터 끝까지 읽고 쓰는 것을 의미합니다.

• 장점

AOF는 내구성이 뛰어나고 문제가 발생하면 데이터의 마지막 순간만 손실되므로 안정성과 데이터 무결성이 크게 향상됩니다. 따라서 fsync 작업을 사용하여 AOF를 초당 한 번씩 백업할 수 있습니다.

• 로그 로그 형식으로 추가합니다. 디스크가 가득 차면 redis-check-aof 도구가 실행됩니다.

• 데이터가 너무 크면 Redis는 백그라운드에서 자동으로 aof를 다시 쓸 수 있습니다. Redis가 이전 파일에 로그를 계속 추가하면 다시 쓰기도 매우 안전하며 클라이언트의 읽기 및 쓰기 작업에 영향을 미치지 않습니다.

• AOF 로그에 포함된 모든 쓰기 작업을 사용하면 Redis를 더 쉽게 구문 분석하고 복구할 수 있습니다.

• 단점

동일한 데이터, 동일한 데이터인 AOF는 RDB보다 큽니다.

• 다양한 동기화 메커니즘의 경우 AOF는 RDB보다 느립니다. AOF는 쓰기를 위해 매초 백업되기 때문입니다. 연산이므로 RDB보다 약간 낮습니다. 1초마다 fsync를 백업하는 것은 문제가 없지만, 클라이언트가 쓸 때마다 fsync 백업을 수행하면 redis의 성능이 저하됩니다.

• AOF에는 버그가 있습니다. 즉, 데이터 복구 중에 데이터가 불완전합니다. 이로 인해 AOF는 RDB만큼 간단하지 않기 때문에 AOF가 더 취약해지고 버그가 발생하기 쉽습니다. 그러나 버그를 방지하기 위해 AOF는 그렇지 않습니다. 당시 캐시에 존재했던 데이터 명령어를 기반으로 명령어를 재구성하는 것이 아니라, 더욱 강력하고 신뢰성이 높습니다.

• AOF 구성

`# AOF 默认关闭，yes可以开启
appendonly no

# AOF 的文件名
appendfilename "appendonly.aof"

# no：不同步
# everysec：每秒备份，推荐使用
# always：每次操作都会备份，安全并且数据完整，但是慢性能差
appendfsync everysec

# 重写的时候是否要同步，no可以保证数据安全
no-appendfsync-on-rewrite no

# 重写机制：避免文件越来越大，自动优化压缩指令，会fork一个新的进程去完成重写动作，新进程里的内存数据会被重写，此时旧的aof文件不会被读取使用，类似rdb
# 当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m，满足两者则触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb`

RDB를 사용해야 할까요, AOF를 사용해야 할까요?

일정 기간 동안 캐시 손실을 감수할 수 있다면 RDB를 사용하세요

• 실시간 데이터에 좀 더 주의한다면 AOF를 사용하세요

• 지속성을 위해 RDB와 AOF를 함께 사용하세요. RDB는 서로 다른 시간에 다른 버전을 복원할 수 있는 콜드 백업으로 사용되며, AOF는 핫 백업으로 사용되어 데이터가 1초 동안만 손실되도록 합니다. AOF가 손상되어 사용할 수 없는 경우 RDB를 사용하여 복원하여 둘을 결합합니다. 즉, Redis 복구는 AOF를 먼저 로드하고 AOF에 문제가 있으면 RDB를 다시 로드하므로 핫 및 콜드 백업의 목적을 달성합니다.

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

위 내용은 Redis의 지속성 메커니즘에 대해 이야기해 보겠습니다. RDB를 사용해야 할까요? 아니면 AOF를 사용해야 할까요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!