Redis 지속성 원칙 살펴보기-Redis-php.cn

Redis 지속성 원칙 살펴보기

Redis의 지속성 원리를 자세히 살펴보세요

Redis는 데이터의 지속성을 보장하기 위해 RDB와 AOF라는 두 가지 지속성 방법을 제공합니다. Redis는 인메모리 데이터베이스입니다. 데이터베이스는 데이터의 지속성을 보장하기 위해 RDB와 AOF라는 두 가지 지속성 방법을 각각 제공합니다. 이 두 가지 지속성 방법의 구현 원리를 각각 살펴보겠습니다.

RDB(기본값)

RDB는 특정 조건이 충족되면 자동으로 메모리의 데이터를 디스크에 유지합니다.

스냅샷을 실행하는 타이밍

은 사용자 정의 구성된 스냅샷 규칙을 따릅니다. (redis.conf에서 구성, 아래 자세히 설명)

save 또는 bgsave 명령 실행

마스터-슬레이브 복제 작업 실행(처음)
(추천 무료 학습 비디오 튜토리얼:
mysql 동영상 튜토리얼
)

도식

스냅샷 과정, 즉 파일을 생성하는 과정에서 스냅샷이 생성될 때까지 원본 rdb 파일은 수정되지 않으며, 이전 파일은 직접 수정됩니다. rdb 파일이 항상 완전하도록 새 파일로 교체하세요.

Redis 지속성 원칙 살펴보기 rdb 파일을 정기적으로 백업하면 redis 데이터를 백업할 수 있습니다. RDB는 압축된 바이너리 파일로 공간을 적게 차지하고 전송에 도움이 됩니다.

###스냅샷 설정 규칙은 {얼마나 많은 초} {데이터를 얼마나 절약합니까? 변경되었습니다 }
예: save 100 1: 100초 내에 하나 이상의 키가 수정되면 스냅샷을 찍습니다. save 200 4: 200초 내에 4개 이상의 키가 수정되면 스냅샷을 찍습니다.

RDB의 장점과 단점

단점: 지속성을 위해 RDB를 사용하면 redis가 갑자기 비정상적으로 종료되면 마지막 스냅샷 이후의 데이터가 손실됩니다. 그러나 데이터 손실을 줄이고 허용 범위 내에 있는지 확인하기 위해 조합을 기반으로 자동 스냅샷을 설정할 수 있습니다. 데이터가 더 중요하다면 AOF 방법을 사용할 수 있습니다

장점: RDB 방법을 사용하면 Redis 성능을 극대화할 수 있습니다. 스냅샷 프로세스 중에 기본 프로세스는 하위 프로세스만 분기하면 되며 모든 프로세스는 나머지 작업은 하위 프로세스에서 수행됩니다. 완료되면 상위 프로세스는 디스크 I/O 작업을 수행할 필요가 없습니다. 그러나 데이터 세트가 큰 경우 하위 프로세스를 분기하는 데 시간이 많이 걸리므로 Redis가 일정 기간 동안 요청 처리를 중지하게 됩니다.

AOF 방법
기본적으로 redis는 AOF(파일만 추가)를 활성화하지 않습니다. AOF를 시작한 후 redis는 redis 데이터를 변경하라는 명령을 받을 때마다 하드 디스크의 AOF 파일에 해당 명령을 씁니다. 분명히 이 프로세스는 Redis의 성능을 저하시키지만, 동시에 더 나은 성능의 하드 디스크를 사용하면 AOF 성능을 향상시킬 수 있습니다

AOF 구성 방법

# 开启appendonly参数appendonly true# 设置AOF文件位置dir ./# 设置AOF文件名称，默认是appendonly.aofappendfilename appendonly.aof<br/>

로그인 후 복사

Schematic

RESP 프로토콜

Redis 클라이언트는 RESP 프로토콜을 사용하여 Redis 서버와 통신합니다. 이 프로토콜은 Redis용으로 특별히 설계되었지만 다른 C-S 프로젝트에도 사용할 수 있습니다. Redis 지속성 원칙 살펴보기

간격 기호: Linux에서는 rn, Windows에서는 n

간단한 문자열은 '+'로 시작

AOF 원리 설명
redis는 모든 쓰기 명령을 AOF 파일에 기록하여 데이터를 유지합니다. AOF 파일에 명령을 기록하는 프로세스는 세 단계로 나눌 수 있습니다:

명령 전파

캐시 추가

명령 전파
redis는 명령, 명령 매개변수, 명령을 실행합니다. 매개변수 셀과 기타 내용은 AOF 프로그램으로 전송됩니다. Redis 클라이언트는 명령을 실행할 때 연결을 통해 프로토콜 텍스트를 Redis로 보냅니다. Redis는 프로토콜 텍스트를 받은 후 내용에 따라 적절한 명령 기능을 선택하고 명령 이후에 프로토콜 텍스트를 Redis 문자열 개체로 변환합니다. 함수가 실행된 후 명령 매개변수를 AOF 프로그램으로 보냅니다.

缓存追加

AOF程序接收到命令参数之后，会将其从字符串对象转换成协议内容，再将协议内容追加到AOF缓存中。AOF缓存是在redisServer结构的aof_buf中，新的内容会被追加到aof_buf末尾。aof_buf保持着所有未被写入到AOF文件的协议文本。

文件写入和保存

将AOF缓存内容写入到AOF文件，并保持到磁盘。当服务器的常规函数被执行，或者事件处理器被执行的时候，flushAppendOnlyFile函数将会被执行。会有以下两个过程。

WRITE:将AOF缓存中的内容写入到AOF文件
SAVE:调用fsync或者fdatasync函数，将AOF文件保存到磁盘中

AOF一共有三种保存模式

AOF_FSYNC_NO:不保存。在这种模式下，每次调用flushAppendOnlyFile函数，write会被执行，而save会被忽略。而save只有在以下三种条件下会触发，redis关闭，aof功能关闭，系统的写缓存被刷新(可能是缓存满了，或者定期执行保持操作)。这三种情况下执行save操作会引起redis主线程的阻塞。
AOF_FSYNC_EVERYSEC(默认):每秒保存一次。save每秒被执行一次，但是save由后台子线程完成，不会导致redis主线程阻塞。
AOF_FSYNC_ALWAYS:每执行一个命令保存一次。这种情况下，每执行一个命令write和save都会被执行，而且save操作由主线程完成，会导致redis的阻塞。安全性较高，性能较差，因此不推荐使用。

AOF的文件优化

Redis可以在AOF文件过大的时候，在后台(子进程)对AOF文件进行重写。重写之后的新文件，包含恢复当前数据集所需的最小命令集合。重写，并不会对AOF文件进行读取和写入，针对的是数据库中的当前键。

优化前set s1 1set s1 2set s1 3优化后set s1 3<br/>

로그인 후 복사

AOF文件优化原理

AOF的重写是通过子进程实现的，因此，主线程是继续工作的，有可能对新的数据进行修改，有可能会导致数据库的数据和重写之后的数据不一致。redis通过增加一个AOF重写缓存来解决这个问题，当fork出子进程之后，新的命令不仅会追加到现有的AOF文件中，还会添加一份数据到这个缓存当中。

Redis 지속성 원칙 살펴보기

重写过程分析(需要保证从写的操作是绝对安全的)

Redis创建新的AOF文件之后，会继续将命令添加到原有的AOF文件中，即使数据库突然宕机了，原有的AOF文件和文件内容也不会有损失。而当新的AOF文件创建完毕之后，会直接把旧的替换掉，往新的AOF文件中添加命令。

当子进程在进行重写时，主进程会完成下列工作

处理请求，将新的命令继续添加到AOF文件中，同时将命令添加到AOF重写缓存中。保证数据的一致行，避免出现数据丢失。
当子进程重写完毕之后会向主进程发送一个完成信号，这时主进程会把重写缓存中的内容添加到新的AOF文件中，这样新的AOF文件，数据库，旧的AOF文件的内容就完全一致了。然后对新的AOF文件改名，覆盖原有的AOF文件。

这样程序就完成了新旧AOF文件的替换工作。而当处理完成之后，主进程就会继续接受请求。整个重写过程中只有最后的缓存写入和改名替换的操作会导致主进程阻塞，其他时候不会影响redis的正常工作，把AOF重写对redis的性能影响降到最低。

优化触发条件

#当前的AOF文件超过上次重写时AOF文件大小百分几的时候进行重写，如果没有重写过，则以启动时AOF文件的大小为准auto-aof-rewrite-percentage 100#限制允许重写的最小的AOF文件，也就是文件小于这个值的时候不需要进行重写优化auto-aof-rewrite-min-size 64mb<br/>

로그인 후 복사