Redis 지속성을 구현하는 방법

Redis는 고급 키-값 데이터베이스입니다. Memcached와 유사하지만 데이터가 유지될 수 있고 광범위한 데이터 유형을 지원합니다. 문자열, 연결 목록, 집합, 정렬 집합이 있습니다. 서버 측에서 집합의 합집합, 교집합, 보수(차이) 계산을 지원하고 다양한 정렬 기능도 지원합니다.

Redis는 RDB와 AOF라는 두 가지 지속성 메커니즘을 지원합니다. 지속성은 비정상적인 프로세스 종료 또는 종료로 인한 데이터 손실을 방지할 수 있습니다. 이전 지속성 파일을 사용하여 다음 다시 시작 시 데이터를 복구할 수 있습니다.

RDB 지속성

RDB 지속성은 압축된 바이너리 파일 스냅샷을 생성하여 특정 시점의 전체 데이터를 저장하는 지속성 방법입니다. RDB 지속성은 Redis의 기본 지속성 방법입니다. RDB 지속성 트리거에는 수동 트리거와 자동 트리거가 포함됩니다.

save를 수동으로 실행하여 스냅샷을 동기식으로 저장하는 rdb 파일을 생성하세요. 이렇게 하면 프로덕션 환경에서 bgsave를 실행하지 마세요. 명령줄의 bgsave 명령은 하위 프로세스가 rdb 파일을 생성하여 비동기 방식으로 스냅샷을 저장합니다. 분기 중 차단을 제외하고 하위 프로세스가 rdb 파일을 생성하면 기본 프로세스가 계속 처리할 수 있습니다. 요청

자동으로 트리거

redis.conf에서 save m n을 정기적으로 트리거하도록 구성합니다. 예를 들어 save 900 1은 900초 이내에 업데이트가 하나 이상 있을 때 슬레이브 노드가 a를 수행하는 경우 마스터-슬레이브 복제가 트리거됨을 의미합니다. 전체 복제 작업을 수행하면 마스터 노드는 자동으로 bgsave를 실행하여 RDB 파일을 생성하고 이를 슬레이브 노드로 보냅니다. Redis를 다시 로드할 때 debug reload 명령을 실행하고 종료를 실행합니다. 그리고 AOF 지속성의 RDB 지속성 구성은 그렇지 않습니다. on

# 只要满足下列条件之一，则会执行bgsave命令save 900 1 # 在900s内存在至少一次写操作save 300 10
save 60 10000# 禁用RBD持久化，可在最后加 save ""# 当备份进程出错时主进程是否停止写入操作stop-writes-on-bgsave-error yes# 是否压缩rdb文件 推荐no 相对于硬盘成本cpu资源更贵rdbcompression no

AOF persistence

AOF(Append-Only-File) 지속성은 데이터베이스 상태를 변경하는 모든 명령을 기록하고 이를 AOF 파일에 Append Middle 형식으로 추가합니다. 다시 작성하는 한 가지 방법은 다음과 같습니다. 서버가 다시 시작되면 AOF 파일에 기록된 명령을 사용하여 이전에 종료되었던 데이터베이스 상태를 복원할 수 있습니다.

redis.conf의 AOF 지속성 구성은 다음과 같습니다

# 默认关闭AOF，若要开启将no改为yesappendonly no# append文件的名字appendfilename "appendonly.aof"# 每隔一秒将缓存区内容写入文件 默认开启的写入方式appendfsync everysec# 当AOF文件大小的增长率大于该配置项时自动开启重写（这里指超过原大小的100%）。auto-aof-rewrite-percentage 100# 当AOF文件大小大于该配置项时自动开启重写auto-aof-rewrite-min-size 64mb

AOF 지속성 구현에는 3단계가 포함됩니다.

명령 추가: AOF 버퍼 파일에 명령 추가 쓰기: 버퍼 내용을 AOF 파일에 쓰기 파일 저장 : AOF 파일을 디스크에 저장하는 마지막 두 단계의 빈도는appendfsync를 통해 구성됩니다.appendfsync의 옵션에는 명령이 실행될 때마다 파일을 저장하는

always가 포함됩니다. 이는 보안이 가장 높으며 데이터만 손실됩니다. 최대 하나의 명령이지만 성능도 가장 낮습니다(디스크 IO) Everysec, 1초에 한 번씩 저장됨, 권장됨, 보안과 성능의 절충, 최대 1초 동안 데이터 손실 없음, 운영 체제에 따라 다름 실행 시(일반적으로 약 30초마다) 보안이 가장 낮고 성능이 가장 높으며, 운영 체제가 AOF 파일에 대해 마지막으로 SAVE 작업을 트리거한 이후에는 save 명령을 통해 데이터가 손실됩니다. Redis는 AOF 파일을 다시 작성하여 문제가 커지는 문제(파일의 디스크 점유율을 줄이고 데이터 복구 속도를 높일 수 있음)를 해결합니다.

하위 프로세스를 생성하려면 포크를 호출하세요.

하위 프로세스는 현재 데이터베이스의 상태를 읽어 새로운 AOF 파일을 "다시 작성"합니다(여기서는 "다시 작성"이라고 하지만 이전 파일은 실제로 전혀 읽히지 않지만, 지침은 데이터베이스의 현재 상태에 따라 형성됩니다)

주 프로세스는 동시에 AOF 다시 쓰기에 새로운 변경 사항을 계속해서 씁니다. 버퍼와 원래 AOF 버퍼

주 프로세스는 하위 프로세스가 완료되었다는 신호를 받습니다. AOF를 다시 작성하고, 신호 처리 기능을 호출하여 AOF 다시 쓰기 버퍼의 내용을 새 AOF 파일에 쓰고, 새 파일의 이름을 바꾸고, 원본 AOF 파일을 원자적으로 덮어쓰고 이전 파일과 새 파일의 교체를 완료합니다.

AOF 다시 쓰기. 수동 트리거링과 자동 트리거링으로 구분됩니다.

手动触发： 直接调用bgrewriteaof命令
自动触发： 根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。其中auto-aof-rewrite-min-size表示运行AOF重写时文件最小体积，默认为64MB。auto-aof-rewrite-percentage表示当前AOF文件大小（aof_current_size）和上一次重写后AOF文件大小（aof_base_size）的比值。自动触发时机为 aof_current_size > auto-aof-rewrite-min-size &&（aof_current_size - aof_base_size）/aof_base_size> = auto-aof-rewrite-percentage

RDB와 AOF

RDB 및 AOF에는 각각의 장점과 단점이 있습니다.

RDB의 장점: AOF에 비해 RDB 파일은 상대적으로 작고 데이터 복구가 더 빠릅니다. (이유는 데이터 복구 섹션 참조) RDB의 단점: 서버가 다운되면 RBD 방법은 마지막 RDB 이후의 데이터를 잃게 됩니다. 지속성; bgsave를 사용하여 하위 프로세스를 포크할 때 메모리가 소비됩니다. AOF의 장점: AOF는 파일만 추가하고 서버 성능에 미치는 영향이 적으며 RDB보다 빠르고 메모리를 덜 소모하며 가독성이 높습니다. AOF를 사용하면 두 가지 단점이 있습니다. 생성된 파일이 상대적으로 크고, AOF로 다시 작성하더라도 여전히 상대적으로 크고, 데이터 복구 속도도 RDB보다 느립니다. 데이터베이스 복구

AOF 지속성 기능이 켜져 있지 않으면 서버가 시작될 때 RDB 파일이 자동으로 로드되는 동안 기본 프로세스가 차단됩니다. AOF 지속성 기능이 켜져 있으면 서버는 AOF 파일을 사용하여 데이터베이스 상태를 복원하는 데 우선 순위를 부여합니다. 왜냐하면 AOF 파일의 업데이트 빈도는 일반적으로 RDB 파일의 업데이트 빈도보다 높고 저장된 데이터는 더 완전하기 때문입니다.

redis 데이터베이스 복구의 처리 흐름은 다음과 같습니다.

데이터 복구 측면에서 RDB의 시작 시간은 두 가지 이유로 더 짧아집니다.

RDB 파일에는 각 데이터 항목에 대해 하나의 레코드만 있습니다. AOF 로그와 달리 하나의 데이터 항목에 대한 작업 기록이 여러 개 있을 수 있습니다. 따라서 각 데이터 조각은 한 번만 작성하면 되며 파일은 상대적으로 작습니다.

RDB 文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作，所以在CPU消耗上要远小于AOF日志的加载。

但是在进行RDB持久化时，fork出来进行dump操作的子进程会占用与父进程一样的内存，采用的copy-on-write机制，对性能的影响和内存的消耗都是比较大的。比如16G内存，Redis已经使用了10G，这时save的话会再生成10G，变成20G，大于系统的16G。这时候会发生交换，要是虚拟内存不够则会崩溃，导致数据丢失。所以在用redis的时候一定对系统内存做好容量规划。

RDB、AOF混合持久化

Redis从4.0版开始支持RDB与AOF的混合持久化方案。首先由RDB定期完成内存快照的备份，然后再由AOF完成两次RDB之间的数据备份，由这两部分共同构成持久化文件。这个方案的优势在于其充分利用了RDB加载速度快、备份体积小以及AOF记录数据丢失几率尽可能低的特点。缺点是兼容性差，一旦开启了混合持久化，在4.0之前的版本都不识别该持久化文件，同时由于前部分是RDB格式，阅读性较低。

开启混合持久化

aof-use-rdb-preamble yes

数据恢复加载过程就是先按照RDB进行加载，然后把AOF命令追加写入。

持久化方案的建议 如果Redis只是用来做缓存服务器，比如数据库查询数据后缓存，那可以不用考虑持久化，因为缓存服务失效还能再从数据库获取恢复。建议同时采用两种持久化方式，以提高数据的安全性。如果你可以容忍在灾难发生时数据丢失几分钟，那么可以仅使用RDB。一般的设计方法是 使用主从复制机制以解决持久化时所带来的性能影响。即Master上RDB、AOF都不做，保证Master的读写性能，而Slave上则同时开启RDB和AOF（或4.0以上版本的混合持久化方式）来进行持久化，保证数据的安全性。

위 내용은 Redis 지속성을 구현하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!