Redis 클래식 기술의 지속성 원칙에 대한 자세한 설명

如前面提到的，Redis长时间运行，命令不断写入AOF，文件会越来越大，不加控制可能影响宿主机的安全。

为了解决AOF文件体积问题，Redis引入了AOF文件重写功能，它会根据Redis内数据对象的最新状态生成新的AOF文件，新旧文件对应的数据状态一致，但是新文件会具有较小的体积。重写既减少了AOF文件对磁盘空间的占用，又可以提高Redis重启时数据恢复的速度。还是下面这个例子，旧文件中的6条命令等同于新文件中的1条命令，压缩效果显而易见。我们说，AOF文件太大时会触发AOF文件重写，那到底是多大呢？有哪些情况会触发重写操作呢？** 与RDB方式一样，AOF文件重写既可以手动触发，也会自动触发。手动触发直接调用bgrewriteaof命令，如果当时无子进程执行会立刻执行，否则安排在子进程结束后执行。自动触发由Redis的周期性方法serverCron检查在满足一定条件时触发。先了解两个配置项：

• auto-aof-rewrite-percentage：代表当前AOF文件大小（aof_current_size）和上一次重写后AOF文件大小（aof_base_size）相比，增长的比例。

• auto-aof-rewrite-min-size：表示运行BGREWRITEAOF时AOF文件占用空间最小值，默认为64MB；

Redis启动时把aof_base_size初始化为当时aof文件的大小，Redis运行过程中，当AOF文件重写操作完成时，会对其进行更新；aof_current_size为serverCron执行时AOF文件的实时大小。当满足以下两个条件时，AOF文件重写就会触发：

增长比例：(aof_current_size - aof_base_size) / aof_base_size > auto-aof-rewrite-percentage 文件大小：aof_current_size > auto-aof-rewrite-min-size

手动触发与自动触发的代码如下，同样在周期性方法serverCron中：

int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) { /* 省略其他逻辑 */ /* 如果用户请求进行AOF文件重写时，Redis正在执行RDB持久化，Redis会安排在RDB持久化完成后执行AOF文件重写， * 如果aof_rewrite_scheduled为true，说明需要执行用户的请求 */ if (!hasActiveChildProcess() && server.aof_rewrite_scheduled) { rewriteAppendOnlyFileBackground(); } /* Check if a background saving or AOF rewrite in progress terminated. */ if (hasActiveChildProcess() || ldbPendingChildren()) { run_with_period(1000) receiveChildInfo(); checkChildrenDone(); } else { /* 省略rdb持久化条件检查 */ /* AOF重写条件检查：aof开启、无子进程运行、增长百分比已设置、当前文件大小超过阈值 */ if (server.aof_state == AOF_ON && !hasActiveChildProcess() && server.aof_rewrite_perc && server.aof_current_size > server.aof_rewrite_min_size) { long long base = server.aof_rewrite_base_size ? server.aof_rewrite_base_size : 1; /* 计算增长百分比 */ long long growth = (server.aof_current_size*100/base) - 100; if (growth >= server.aof_rewrite_perc) { serverLog(LL_NOTICE,"Starting automatic rewriting of AOF on %lld%% growth",growth); rewriteAppendOnlyFileBackground(); } } } /**/ }

AOF文件重写的流程是什么？听说Redis支持混合持久化，对AOF文件重写有什么影响？

从4.0版本开始，Redis在AOF模式中引入了混合持久化方案，即：纯AOF方式、RDB+AOF方式，这一策略由配置参数aof-use-rdb-preamble（使用RDB作为AOF文件的前半段）控制，默认关闭(no)，设置为yes可开启。所以，在AOF重写过程中文件的写入会有两种不同的方式。当aof-use-rdb-preamble的值是：

• no：按照AOF格式写入命令，与4.0前版本无差别；

• yes：先按照RDB格式写入数据状态，然后把重写期间AOF缓冲区的内容以AOF格式写入，文件前半部分为RDB格式，后半部分为AOF格式。

结合源码（6.0版本，源码太多这里不贴出，可参考aof.c）及参考资料，绘制AOF重写（BGREWRITEAOF）流程图：结合上图，总结一下AOF文件重写的流程：

• rewriteAppendOnlyFileBackground开始执行，检查是否有正在进行的AOF重写或RDB持久化子进程：如果有，则退出该流程；如果没有，则继续创建接下来父子进程间数据传输的通信管道。执行fork()操作，成功后父子进程分别执行不同的流程。

• 父进程：

  • 记录子进程信息（pid）、时间戳等；

  • 继续响应其他客户端请求；

  • 收集AOF重写期间的命令，追加至aof_rewrite_buffer；

  • 等待并向子进程同步aof_rewrite_buffer的内容；

• 子进程：

  • 修改当前进程名称，创建重写所需的临时文件，调用rewriteAppendOnlyFile函数；

  • 根据aof-use-rdb-preamble配置，以RDB或AOF方式写入前半部分，并同步至硬盘；

  • 从父进程接收增量AOF命令，以AOF方式写入后半部分，并同步至硬盘；

  • 重命名AOF文件，子进程退出。

数据加载

Redis启动后通过loadDataFromDisk函数执行数据加载工作。这里需要注意，虽然持久化方式可以选择AOF、RDB或者两者兼用，但是数据加载时必须做出选择，两种方式各自加载一遍就乱套了。

이론적으로 AOF 지속성은 RDB보다 실시간 성능이 더 좋습니다. AOF 지속성을 활성화하면 Redis는 데이터를 로드할 때 AOF에 우선순위를 부여합니다. 또한 Redis 4.0 버전 이후에는 AOF가 하이브리드 지속성을 지원하므로 AOF 파일을 로드할 때 버전 호환성을 고려해야 합니다. Redis 데이터 로딩 과정은 아래 그림과 같습니다.AOF 모드에서 하이브리드 지속성 메커니즘을 켜면 생성되는 파일은 "RDB 헤더 + AOF 테일"입니다. 켜지지 않으면 생성되는 파일은 모두 AOF에 있습니다. 체재. 두 파일 형식의 호환성을 고려하여 Redis가 AOF 파일이 RDB 헤더임을 발견하면 RDB 데이터 로딩 방법을 사용하여 전반부를 읽고 복원한 다음 AOF 방법을 사용하여 후반부를 읽고 복원합니다. . AOF 형식으로 저장된 데이터는 RESP 프로토콜 명령이므로 Redis는 의사 클라이언트를 사용하여 명령을 실행하여 데이터를 복구합니다.

AOF 명령을 추가하는 과정에서 다운타임이 발생하면 쓰기 지연의 기술적 특성으로 인해 AOF의 RESP 명령이 불완전(잘림)될 수 있습니다. 이러한 상황이 발생하면 Redis는aof-load-truncated구성 항목에 따라 다양한 처리 전략을 실행합니다. 이 구성은 Redis가 시작할 때 aof 파일을 읽도록 지시하고, 파일이 잘린(불완전) 것으로 발견되면 어떻게 해야 하는지 알려줍니다.aof-load-truncated执行不同的处理策略。这个配置是告诉Redis启动时读取aof文件，如果发现文件被截断（不完整）时该如何处理：

• yes：则尽可能多的加载数据，并以日志的方式通知用户；

• no：则以系统错误的方式崩溃，并禁止启动，需要用户修复文件后再重启。

总结

Redis提供了两种持久化的选择：RDB支持以特定的实践间隔为数据集生成时间点快照；AOF把Redis Server收到的每条写指令持久化到日志中，待Redis重启时通过重放命令恢复数据。日志格式为RESP协议，对日志文件只做append操作，无损坏风险。并且当AOF文件过大时可以自动重写压缩文件。

当然，如果你不需要对数据进行持久化，也可以禁用Redis的持久化功能，但是大多数情况并非如此。实际上，我们时有可能同时使用RDB和AOF两种方式的，最重要的就是我们要理解两者的区别，以便合理使用。

RDB vs AOF

RDB优点

• RDB是一个紧凑压缩的二进制文件，代表Redis在某一个时间点上的数据快照，非常适合用于备份、全量复制等场景。

• RDB对灾难恢复、数据迁移非常友好，RDB文件可以转移至任何需要的地方并重新加载。

• RDB是Redis数据的内存快照，数据恢复速度较快，相比于AOF的命令重放有着更高的性能。

RDB缺点

• RDB方式无法做到实时或秒级持久化。因为持久化过程是通过fork子进程后由子进程完成的，子进程的内存只是在fork操作那一时刻父进程的数据快照，而fork操作后父进程持续对外服务，内部数据时刻变更，子进程的数据不再更新，两者始终存在差异，所以无法做到实时性。

• RDB持久化过程中的fork操作，会导致内存占用加倍，而且父进程数据越多，fork过程越长。

• Redis请求高并发可能会频繁命中save规则，导致fork操作及持久化备份的频率不可控；

• RDB文件有文件格式要求，不同版本的Redis会对文件格式进行调整，存在老版本无法兼容新版本的问题。

AOF优点

• AOF持久化有更好的实时性，我们可以选择三种不同的方式（appendfsync）：no、every second、always，every second作为默认的策略具有最好的性能，极端情况下可能会丢失一秒的数据。

• AOF文件只有append操作，无复杂的seek等文件操作，没有损坏风险。即使最后写入数据被截断，也很容易使用redis-check-aof

• yes: 가능한 한 많은 데이터를 로드하고 로그 형식으로 사용자에게 알립니다. ;

• no: 시스템 오류로 인해 충돌이 발생하여 시작할 수 없습니다. 사용자가 파일을 복구한 후 다시 시작해야 합니다.

요약

• Redis는 두 가지 지속성 옵션을 제공합니다. RDB는 특정 실제 간격으로 데이터 세트에 대한 특정 시점 스냅샷 생성을 지원합니다. AOF는 Redis 서버에서 수신한 각 쓰기 명령을 로그에 유지하고 복원합니다. Redis가 다시 시작될 때 재생 명령을 통해 데이터를 가져옵니다. 로그 형식은 RESP 프로토콜이며 로그 파일에 추가 작업만 수행되므로 손상될 위험이 없습니다. AOF 파일이 너무 크면 압축 파일을 자동으로 다시 작성할 수 있습니다.
  물론 데이터를 유지할 필요가 없다면 Redis의 지속성 기능을 비활성화할 수도 있지만 대부분의 경우 그렇지 않습니다. 실제로 RDB와 AOF를 동시에 사용하는 경우가 있는데, 가장 중요한 것은 RDB와 AOF를 합리적으로 사용하기 위해서는 둘의 차이점을 이해하는 것입니다.

RDB 대 AOF

• RDB는 특정 시점의 Redis 데이터 스냅샷을 나타내는 압축된 소형 바이너리 파일입니다. 백업, 전체 복사 및 기타 시나리오에 적합합니다.

• RDB는 재해 복구 및 데이터 마이그레이션에 매우 친숙합니다. RDB 파일은 필요한 곳으로 이동하고 다시 로드할 수 있습니다.
  RDB는 Redis 데이터의 메모리 스냅샷으로, AOF 명령 재생보다 데이터 복구 속도가 빠르고 성능도 높습니다. RDB 단점 RDB 방식은 실시간 또는 2차 지속성을 달성할 수 없습니다. 자식 프로세스를 포크한 후 자식 프로세스에 의해 지속성 프로세스가 완료되기 때문에 자식 프로세스의 메모리는 포크 작업 이후 부모 프로세스의 데이터에 대한 스냅샷일 뿐입니다. 외부 세계에 서비스를 제공하고 내부 데이터는 항상 변경되며 데이터는 더 이상 업데이트되지 않으며 둘 사이에는 항상 차이가 있으므로 실시간 성능을 달성할 수 없습니다. RDB 지속성 프로세스 중 포크 작업은 메모리 사용량을 두 배로 늘리고 상위 프로세스에 데이터가 많을수록 포크 프로세스가 길어집니다. Redis 요청의 높은 동시성은 자주 저장 규칙에 도달하여 포크 작업 및 영구 백업의 빈도를 제어할 수 없게 만들 수 있습니다. RDB 파일에는 파일 형식 요구 사항이 있으며 다양한 버전의 Redis에서 파일 형식이 조정됩니다. . 이전 버전은 새 버전과 호환되지 않습니다. AOF 장점AOF 지속성은 더 나은 실시간 성능을 제공하며 세 가지 다른 방법(appendfsync)을 선택할 수 있습니다. 아니요, 매초, 항상, 기본 전략이 최고의 성능을 가지므로 매초, 1초 극단적인 경우 데이터가 손실될 수 있습니다. AOF 파일에는 추가 작업만 있고 복잡한 탐색 및 기타 파일 작업이 없으며 손상 위험이 없습니다. 마지막으로 작성된 데이터가 잘려도redis-check-aof도구를 사용하여 쉽게 복구할 수 있습니다. AOF 파일이 커지면 Redis가 백그라운드에서 자동으로 다시 쓸 수 있습니다. 다시 쓰는 동안 이전 파일은 계속해서 쓰여집니다. 다시 쓰기가 완료된 후에는 새 파일의 크기가 작아지고 다시 쓰는 동안의 증분 명령도 새 파일에 추가됩니다. AOF 파일에는 Redis의 데이터에 대한 모든 작업 명령이 이해하기 쉽고 구문 분석하기 쉬운 방식으로 포함되어 있습니다. 실수로 모든 데이터를 삭제하더라도 AOF 파일을 다시 쓰지 않는 한 마지막 명령을 제거하면 모든 데이터를 복구할 수 있습니다. AOF는 이미 하이브리드 지속성을 지원하고 파일 크기를 효과적으로 제어할 수 있으며 데이터 로딩 효율성이 향상됩니다. AOF 단점 동일한 데이터 수집의 경우 AOF 파일은 일반적으로 RDB 파일보다 큽니다. 특정 fsync 전략에서 AOF는 RDB보다 약간 느립니다. 일반적으로 fsync_every_second의 성능은 여전히 매우 높으며 fsync_no의 성능은 RDB와 비슷합니다. 그러나 엄청난 쓰기 압력 하에서 RDB는 가장 낮은 지연 시간을 보장할 수 있습니다.

• AOF에서 Redis는 RDB에서는 거의 만날 수 없는 희귀한 버그를 발견한 적이 있습니다. 일부 특수 명령(예: BRPOPLPUSH)으로 인해 다시 로드된 데이터가 지속성 이전의 데이터와 일치하지 않게 되었습니다. Redis 관계자는 동일한 조건에서 테스트했지만 문제를 재현할 수 없었습니다.

사용 제안

RDB와 AOF의 두 Persistence 방식의 작동 원리, 실행 프로세스, 장단점을 이해한 후, 실제 시나리오에서 장단점을 가늠하고 두 Persistence를 어떻게 활용할 수 있을지 생각해 보겠습니다. 방법을 합리적으로. Redis를 캐싱 도구로만 사용하는 경우 영구 데이터베이스를 기반으로 모든 데이터를 재구성할 수 있으며, 지속성 기능을 끄고 예열, 캐시 침투, 고장, 눈사태 등의 보호 작업을 수행할 수 있습니다.

일반적인 상황에서 Redis는 분산 잠금, 순위, 등록 센터 등과 같은 더 많은 작업을 수행합니다. 지속성 기능은 재해 복구 및 데이터 마이그레이션에서 더 큰 역할을 합니다. 다음과 같은 몇 가지 원칙을 따르는 것이 좋습니다.

• Redis를 데이터베이스로 사용하지 마십시오. 모든 데이터는 가능한 한 애플리케이션 서비스에 의해 자동으로 재구성됩니다.

• Redis 버전 4.0 이상을 사용하고 AOF+RDB 하이브리드 지속성 기능을 사용하세요.

• AOF 재작성 또는 저장 중 리소스 부족을 방지하기 위해 Redis가 차지하는 최대 메모리를 합리적으로 계획합니다.

• 단일 머신에 여러 인스턴스를 배포하지 마세요.

• 대부분의 프로덕션 환경은 클러스터에 배포됩니다. 슬레이브에서 지속성 기능을 활성화하여 마스터가 외부 쓰기 서비스를 더 잘 제공할 수 있습니다.

• 재난 백업에 대비하여 백업 파일은 자동으로 외부 전산실이나 클라우드 스토리지에 업로드되어야 합니다.

fork()에 대하여

위의 분석을 통해 우리 모두는 RDB 스냅샷과 AOF 재작성에 포크가 필요하다는 것을 알고 있습니다. 이는 매우 중요한 작업이며 Redis를 차단하게 됩니다. 따라서 Redis 메인 프로세스의 응답에 영향을 주지 않기 위해서는 블로킹을 최대한 줄여야 합니다.

• 포크 빈도를 줄입니다. 예를 들어 RDB를 수동으로 실행하여 스냅샷 및 AOF 재작성을 생성할 수 있습니다.

• 포크가 너무 오래 걸리는 것을 방지하기 위해 Redis의 최대 메모리 사용량을 제어합니다. 성능 하드웨어 ;

• 물리적 메모리 부족으로 인한 포크 실패를 방지하려면 Linux의 메모리 할당 전략을 올바르게 구성하세요

• 권장 학습:

  Redis 학습 튜토리얼

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