Redis에서 다운타임에 대한 두려움 없이 빠른 복구와 지속성을 달성하는 방법

Redis에서 다운타임에 대한 두려움 없이 빠른 복구와 지속성을 달성하는 방법은 무엇입니까? 다음 기사를 통해 이에 대해 안내해 드리겠습니다. 도움이 되기를 바랍니다!

독립적인 것이 옳고, 서클에 통합되는 것이 옳습니다. 핵심은 당신이 원하는 삶의 종류와 그에 대한 대가를 얼마나 지불할 의향이 있는지 파악하는 것입니다.

우리는 읽기 응답 성능을 향상시키기 위해 일반적으로 Redis를 캐시로 사용합니다. Redis가 다운되면 메모리에 있는 모든 데이터가 데이터베이스에 직접 액세스하여 대량의 트래픽이 MySQL에 도달하면 더 심각한 문제가 발생할 수 있습니다. 문제. [관련 권장사항: Redis 동영상 튜토리얼]

또한, 데이터베이스에서 Redis로 천천히 읽는 성능은 필연적으로 Redis에서 가져오는 것보다 빠르며, 이로 인해 응답도 느려집니다.

다운타임에 대한 두려움 없이 빠른 복구를 달성하기 위해 Redis는 AOF(Append Only FIle) 로그와 RDB 스냅샷이라는 두 가지 주요 킬러 기능을 설계했습니다.

기술을 배울 때, 여러분은 대개 머릿속에 완전한 지식 프레임워크와 아키텍처 시스템을 확립하지 못한 채, 체계적인 관점도 없이 흩어져 있는 기술적 포인트만 접하게 됩니다. 이것은 매우 어려운 일이며 언뜻 보면 할 수 있을 것처럼 보이지만 나중에는 잊어버리고 혼란스러울 것입니다.

"Code Byte"를 따라가며 Redis를 철저하게 이해하고, Redis의 핵심 원리와 실무 기술을 심도 있게 마스터하세요. 완전한 지식 프레임워크를 구축하고 글로벌 관점에서 전체 지식 시스템을 구성하는 방법을 배웁니다.

이 글은 하드코어한 글입니다. 저장해 두시고, 좋아요를 누르시고, 진정하시고 읽으시면 많은 이득을 얻으실 것이라 믿습니다.

이전 글에서는 Redis의 핵심 데이터 구조, IO 모델, 스레드 모델을 분석하고, 다양한 데이터에 따라 적절한 데이터 인코딩을 사용했습니다. 정말 빠른 이유를 깊이 파악해보세요!

이 기사에서는 다음 사항에 중점을 둘 것입니다.

• 다운타임 후 빠르게 복구하는 방법은 무엇입니까?
• 다운타임, Redis는 어떻게 데이터 손실을 방지하나요?
• RDB 메모리 스냅샷이란 무엇인가요?
• AOF 로그 구현 메커니즘
• 기록 중 복사 기술이란 무엇인가요?
• ….

관련된 지식 포인트는 그림에 표시된 것과 같습니다.

Redis 파노라마

파노라마는 두 가지 차원으로 확장될 수 있습니다.

응용 프로그램 차원: 캐시 사용량, 클러스터링 애플리케이션 및 데이터 구조의 영리한 사용

시스템 크기: 세 가지 높이로 분류 가능

1. 고성능: 스레드 모델, 네트워크 IO 모델, 데이터 구조, 지속성 메커니즘,
2. 고가용성: 마스터-슬레이브 복제 , Sentinel 클러스터, 클러스터 샤드 클러스터;
3. 높은 확장: 로드 밸런싱

Redis 시리즈 챕터는 다음 마인드맵을 중심으로 진행됩니다. 이번에는 Redis의 고성능 및 지속성 메커니즘의 비밀을 살펴보겠습니다.

파노라마 뷰를 감상하고 시스템 뷰를 마스터하세요.

시스템 뷰는 실제로 어느 정도 중요합니다. 문제를 해결할 때 시스템 뷰를 갖는다는 것은 잘 기반을 잡고 조직적인 방식으로 문제를 찾고 해결할 수 있다는 것을 의미합니다.

RDB 메모리 스냅샷, 다운타임으로부터 빠른 복구 가능

65 Brother: Redis가 어떤 이유로 다운되어 모든 트래픽이 백엔드 MySQL에 도달하게 됩니다. Redis를 즉시 다시 시작했지만 해당 데이터가 존재하는 이유는 무엇입니까? 다시 시작한 후 메모리에 데이터가 없습니다. 다시 시작한 후 데이터 손실을 방지하는 방법은 무엇입니까?

65 걱정하지 마십시오. "코드 바이트"는 Redis 충돌 후 신속하게 복구하는 방법을 단계별로 이해하도록 도와줄 것입니다.

Redis 데이터는 메모리에 저장됩니다. 메모리에 있는 데이터를 디스크에 쓰는 것도 고려할 수 있나요? Redis가 재시작되면 디스크에 저장된 데이터가 메모리에 빠르게 복원되므로 재시작 후에도 정상적인 서비스를 제공할 수 있습니다.

65 형제: 메모리를 작동하기 위해 "쓰기" 작업이 수행될 때마다 동시에 디스크에 기록되는 해결책을 생각했습니다.

이 솔루션에는 치명적인 문제가 있습니다. 메모리뿐만 아니라 디스크에도 쓴다. 메모리에 비해 성능이 너무 느려서 Redis의 성능이 크게 저하된다.

Memory Snapshot

65 형제: 그러면 이 동시 쓰기 문제를 어떻게 방지할 수 있나요?

우리는 일반적으로 Redis를 캐시로 사용하므로 Redis가 모든 데이터를 저장하지 않더라도 데이터베이스를 통해 얻을 수 있으므로 Redis는 모든 데이터를 저장하지 않습니다. "RDB 데이터 스냅샷"을 사용합니다. 다운타임으로부터 신속한 복구를 달성합니다.

65 형제: 그럼 RDB 메모리 스냅샷이란 무엇인가요?

Redis가 "write" 명령을 실행하는 동안 메모리 데이터는 계속 변경됩니다. 소위 메모리 스냅샷은 특정 순간에 Redis 메모리에 있는 데이터의 상태 데이터를 말합니다.

특정 순간에 시간이 정지된 것과 같습니다. 사진을 찍으면 사진을 통해 특정 순간의 순간을 완벽하게 기록할 수 있습니다.

Redis도 이와 비슷합니다. 특정 순간의 데이터를 파일 형식으로 가져와서 디스크에 씁니다. 이 스냅샷 파일은 RDB 파일이라고 하며 Redis DataBase의 약어입니다.

Redis는 정기적으로 RDB 메모리 스냅샷을 실행하므로 "write" 명령이 실행될 때마다 디스크에 쓸 필요가 없고, 메모리 스냅샷이 실행될 때만 디스크에 쓰기만 하면 됩니다. 빠르면서도 깨지지 않는 것을 보장할 뿐만 아니라 내구성도 확보하고 다운타임으로부터 빠르게 복구할 수 있습니다.

데이터 복구를 수행할 때 RDB 파일을 메모리로 직접 읽어 복구를 완료하세요.

65 형제: 어떤 데이터를 스냅샷으로 찍고 있나요? 아니면 얼마나 자주 스냅샷을 찍나요? 이는 스냅샷의 실행 효율성에 영향을 미칩니다.

65 좋아요. 데이터 효율성에 대해 생각하기 시작했어요. 이전 기사에서 우리는 그의 단일 스레드 모델이 메인 스레드를 최대한 차단하는 작업을 피하고 RDB 파일 생성이 메인 스레드를 차단하는 것을 피해야 한다고 결정했다는 것을 배웠습니다.

RDB 전략 생성

Redis는 RDB 파일 생성을 위한 두 가지 지침을 제공합니다.

• save: 메인 스레드에 의해 실행되며 차단됩니다.
• bgsave: glibc 함수 fork를 호출하여 생성됩니다. > 하위 프로세스는 RDB 파일을 작성하는 데 사용됩니다. 스냅샷 지속성은 하위 프로세스에 의해 완전히 처리되며, 상위 프로세스는 계속해서 클라이언트 요청을 처리하고 RDB 파일의 기본 구성을 생성합니다. fork产生一个子进程用于写入 RDB 文件，快照持久化完全交给子进程来处理，父进程继续处理客户端请求，生成 RDB 文件的默认配置。

65 哥：那在对内存数据做「快照」的时候，内存数据还能修改么？也就是写指令能否正常处理？

首先我们要明确一点，避免阻塞和 RDB 文件生成期间能处理写操作不是一回事。虽然主线程没有阻塞，到那时为了保证快照的数据的一致性，只能处理读操作，不能修改正在执行快照的数据。

很明显，为了生成 RDB 而暂停写操作，Redis 是不答应的。

65 哥：那 Redis 如何实现一边处理写请求，同时生成 RDB 文件呢？

Redis 使用操作系统的多进程写时复制技术 COW(Copy On Write) 来实现快照持久化，这个机制很有意思，也很少人知道。多进程 COW 也是鉴定程序员知识广度的一个重要指标。

Redis 在持久化时会调用 glibc 的函数fork产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端请求。

子进程刚刚产生时，它和父进程共享内存里面的代码段和数据段。这时你可以将父子进程想像成一个连体婴儿，共享身体。

这是 Linux 操作系统的机制，为了节约内存资源，所以尽可能让它们共享起来。在进程分离的一瞬间，内存的增长几乎没有明显变化。

bgsave 子进程可以共享主线程的所有内存数据，读取主线程的数据并写入到 RDB 文件。

在执行 SAVE 命令或者BGSAVE命令创建一个新的 RDB 文件时，程序会对数据库中的键进行检查，已过期的键不会被保存到新创建的 RDB 文件中。

当主线程执行写指令修改数据的时候，这个数据就会复制一份副本， bgsave

65 Brother: 메모리 데이터의 "스냅샷"을 찍을 때 메모리 데이터를 계속 수정할 수 있나요? 즉, write 명령이 정상적으로 처리될 수 있는가?

먼저

RDB 파일 생성 중 쓰기 작업을 처리할 수 있는 것과 차단을 방지하는 것은 동일한 것이 아니라는 점을 분명히 해야 합니다. 메인 스레드는 차단되지 않지만 스냅샷 데이터의 일관성을 보장하기 위해 읽기 작업만 처리할 수 있으며 실행 중인 스냅샷의 데이터를 수정할 수 없습니다.

분명히 Redis는 RDB를 생성하기 위해 쓰기 작업이 일시 중지되는 것을 허용하지 않습니다.

65 Brother: Redis는 어떻게 쓰기 요청을 처리하고 동시에 RDB 파일을 생성할 수 있나요?

Redis는 운영 체제의 다중 프로세스

기록 중 복사 기술 COW(기록 시 복사)
• 를 사용하여 스냅샷 지속성을 달성합니다. 이 메커니즘은 매우 흥미롭고 이를 아는 사람은 거의 없습니다. 다중 프로세스 COW는 프로그래머의 지식 범위를 나타내는 중요한 지표이기도 합니다.
  Redis는 지속성 동안 하위 프로세스를 생성하기 위해 glibc 함수 fork를 호출합니다. 스냅샷 지속성은 하위 프로세스에 의해 완전히 처리되며 상위 프로세스는 계속해서 클라이언트 요청을 처리합니다.
• 자식 프로세스가 방금 생성되면 메모리의 코드 세그먼트와 데이터 세그먼트를 상위 프로세스와 공유합니다. 이때 아버지와 아들이 몸을 공유하는 결합된 쌍둥이로서의 과정을 상상할 수 있습니다.
  이것은 Linux 운영체제의 메커니즘입니다. 메모리 자원을 절약하려면 최대한 공유해야 합니다. 프로세스가 분리되는 순간에는 메모리 증가에 눈에 띄는 변화가 거의 없습니다.

bgsave 하위 프로세스는 메인 스레드의 모든 메모리 데이터를 공유하고, 메인 스레드의 데이터를 읽고 RDB 파일에 쓸 수 있습니다.

SAVE 명령 또는 BGSAVE 명령을 실행하여 새 RDB 파일을 생성할 때 프로그램은 데이터베이스의 키를 확인하며 만료된 키는 데이터베이스에 저장되지 않습니다. 새로 생성된 RDB 파일에

메인 스레드가 쓰기 명령을 실행하여 데이터를 수정하면 데이터의 복사본이 만들어집니다. bgsave 하위 프로세스는 복사본 데이터를 읽고 이를 RDB 파일에 씁니다. 메인 스레드는 원본 데이터를 직접 수정할 수 있습니다.

이는 스냅샷의 무결성을 보장할 뿐만 아니라 메인 스레드가 동시에 데이터를 수정할 수 있게 하여 정상적인 비즈니스에 영향을 주지 않습니다.

Redis는 bgsave를 사용하여 현재 메모리에 있는 모든 데이터의 스냅샷을 찍습니다. 이 작업은 백그라운드에서 하위 프로세스에 의해 완료되므로 기본 스레드가 동시에 데이터를 수정할 수 있습니다.

65 Brother: RDB 파일을 1초마다 실행할 수 있나요? 이렇게 하면 다운타임이 발생하더라도 최대 1초의 데이터가 손실됩니다. 🎜🎜🎜전체 데이터 스냅샷을 너무 자주 실행하면 두 가지 심각한 성능 오버헤드가 발생합니다. 🎜🎜🎜🎜자주 RDB 파일을 생성하고 디스크에 기록하면 과도한 디스크 압력이 발생합니다. 이전 RDB가 아직 실행되지 않은 것으로 나타나고 다음 RDB가 다시 생성되기 시작하여 무한 루프에 빠지게 됩니다. 🎜🎜🎜🎜bgsave 하위 프로세스에서 포크하면 메인 스레드가 차단됩니다. 메인 스레드의 메모리가 클수록 차단 시간이 길어집니다. 🎜🎜🎜🎜🎜장점과 단점🎜🎜🎜스냅샷의 복구 속도는 빠르지만 RDB 파일 생성 빈도를 제어하기 어렵습니다. 빈도가 너무 낮으면 가동 중지 시간으로 인해 더 많은 데이터가 손실됩니다. 너무 빠르면 추가 오버헤드가 소비됩니다. 🎜🎜RDB는 바이너리 + 데이터 압축을 사용하여 작은 파일 크기와 빠른 데이터 복구 속도로 디스크에 씁니다. 🎜🎜Redis는 RDB 전체 스냅샷 외에도 AOF 쓰기 후 로그도 설계합니다. 다음으로 AOF 로그가 무엇인지 알아보겠습니다. 🎜🎜🎜다운타임 중 데이터 손실을 방지하기 위한 AOF 쓰기 후 로그🎜🎜🎜AOF 로그는 Redis 서버의 순차적 명령 시퀀스를 저장합니다. AOF 로그는 메모리를 수정하는 명령만 기록합니다. 🎜

AOF 로그가 Redis 인스턴스 생성 이후 수정된 모든 명령 시퀀스를 기록한다고 가정하면, 빈 Redis 인스턴스에서 모든 명령을 순차적으로 실행하는 즉, "재생 중" 상태를 통해 현재 Redis 인스턴스의 메모리 데이터 구조를 복원할 수 있습니다. .

쓰기 전 로그와 쓰기 후 로그 비교

WAL(Write Ahead Log): 실제로 데이터를 쓰기 전에 수정된 데이터가 로그 파일에 기록되므로 장애 복구가 보장됩니다.

예를 들어 MySQL Innodb 스토리지 엔진의 redo 로그는 실제로 데이터를 수정하기 전에 수정 로그를 기록하고 수정된 데이터가 실행되는 데이터 로그입니다.

쓰기 후 로그: 먼저 "쓰기" 명령 요청을 실행하고 메모리에 데이터를 쓴 다음 로그를 기록합니다.

로그 형식

Redis가 메모리에 데이터를 쓰는 "set key MageByte" 명령을 받으면 Redis는 AOF 파일을 다음 형식으로 씁니다.

• "*3": 현재 명령이 세 부분으로 나누어져 있음을 나타냅니다. 각 부분은 "$ + 숫자"로 시작하고 그 뒤에 해당 부분의 특정 "명령, 키, 값"이 옵니다.
• "숫자": 명령, 키 및 값의 이 부분이 차지하는 바이트 크기를 나타냅니다. 예를 들어 "$3"은 이 부분에 "set" 명령인 3바이트가 포함되어 있음을 의미합니다.

65 Brother: Redis는 왜 사후 쓰기 로깅을 사용하나요?

로그 작성 후 추가 검사 오버헤드를 방지하고 실행된 명령의 구문 검사가 필요하지 않습니다. 미리 쓰기 로깅을 사용하는 경우 구문이 올바른지 먼저 확인해야 합니다. 그렇지 않으면 로그에 잘못된 명령이 기록되어 로그 복구 사용 시 오류가 발생합니다.

또한 쓰기 후에는 로그가 기록되므로 현재 "쓰기" 명령의 실행을 차단하지 않습니다.

65 형: 그럼 AOF는 완전 무결점인가요?

멍청한 소년, 그렇게 간단하지 않습니다. Redis가 방금 명령 실행을 마치고 로그를 기록하기 전에 충돌이 발생하면 이 명령과 관련된 데이터가 손실될 수 있습니다.

또한 AOF는 현재 명령을 차단하는 것을 방지하지만 다음 명령을 차단할 위험이 있습니다. AOF 로그는 기본 스레드에 의해 실행됩니다. 디스크에 로그를 쓰는 동안 디스크 압력이 높으면 디스크에 쓰는 속도가 매우 느려져 후속 "쓰기" 명령이 차단됩니다.

이 두 가지 문제가 디스크 쓰기 저장과 관련이 있다는 사실을 알고 계셨나요? "write" 명령이 실행된 후 AOF 로그를 디스크에 다시 쓰는 타이밍을 합리적으로 제어할 수 있다면 문제가 해결될 것입니다.

쓰기 저장 전략

파일 쓰기 효율성을 높이기 위해 사용자가 write 함수를 호출하여 파일에 일부 데이터를 쓸 때 운영 체제는 일반적으로 작성된 데이터를 임시로 메모리에 저장합니다. 버퍼에 있는 데이터는 버퍼 공간이 가득 차거나 지정된 시간 제한을 초과할 때까지 실제로 디스크에 기록되지 않습니다. write 函数，将一些数据写入到文件的时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里面，等到缓冲区的空间被填满、或者超过了指定的时限之后，才真正地将缓冲区中的数据写入到磁盘里面。

这种做法虽然提高了效率，但也为写入数据带来了安全问题，因为如果计算机发生停机，那么保存在内存缓冲区里面的写入数据将会丢失。

为此，系统提供了fsync和fdatasync两个同步函数，它们可以强制让操作系统立即将缓冲区中的数据写入到硬盘里面，从而确保写入数据的安全性。

Redis 提供的 AOF 配置项appendfsync写回策略直接决定 AOF 持久化功能的效率和安全性。

• always：同步写回，写指令执行完毕立马将 aof_buf缓冲区中的内容刷写到 AOF 文件。
• everysec：每秒写回，写指令执行完，日志只会写到 AOF 文件缓冲区，每隔一秒就把缓冲区内容同步到磁盘。
• no： 操作系统控制，写执行执行完毕，把日志写到 AOF 文件内存缓冲区，由操作系统决定何时刷写到磁盘。

没有两全其美的策略，我们需要在性能和可靠性上做一个取舍。

always同步写回可以做到数据不丢失，但是每个「写」指令都需要写入磁盘，性能最差。

everysec每秒写回，避免了同步写回的性能开销，发生宕机可能有一秒位写入磁盘的数据丢失，在性能和可靠性之间做了折中。

no

이 접근 방식은 효율성을 향상시키지만 컴퓨터가 종료되면 메모리 버퍼에 저장된 기록된 데이터가 손실되므로 기록된 데이터에 보안 문제도 발생합니다.

이를 위해 시스템은 fsync 및 fdatasync라는 두 가지 동기화 기능을 제공합니다. 이 기능을 사용하면 운영체제가 버퍼에 있는 데이터를 즉시 하드 디스크에 쓰도록 할 수 있습니다. 따라서 서면 데이터의 보안을 보장합니다.

🎜Redis에서 제공하는 AOF 구성 항목 appendfsync 쓰기 저장 전략은 AOF 지속성 기능의 효율성과 보안을 직접적으로 결정합니다. 🎜🎜🎜🎜always🎜: 동기식 쓰기 저장, 쓰기 명령이 실행된 직후 aof_buf 버퍼의 콘텐츠가 AOF 파일로 플러시됩니다. 🎜🎜🎜everysec🎜: 쓰기 명령이 실행된 후 로그는 AOF 파일 버퍼에만 기록되고 버퍼 내용은 매초 디스크에 동기화됩니다. 🎜🎜🎜no: 🎜 운영 체제에 의해 제어되며 쓰기 실행이 완료된 후 로그가 AOF 파일 메모리 버퍼에 기록되고 운영 체제가 이를 디스크에 플러시할 시기를 결정합니다. 🎜🎜🎜양쪽 모두를 위한 최선의 전략은 없습니다. 성능과 안정성 사이에서 절충점을 찾아야 합니다. 🎜🎜always 동기식 쓰기 저장은 데이터 손실을 방지할 수 있지만 각 "쓰기" 명령은 성능이 가장 나쁜 디스크에 기록되어야 합니다. 🎜🎜everysec는 동기식 쓰기 저장의 성능 오버헤드를 방지하여 매초마다 쓰기를 수행하며, 가동 중지 시간이 발생하면 디스크에 기록된 데이터가 1초 동안 손실되어 성능과 안정성이 절충될 수 있습니다. 🎜🎜no 운영 체제 제어는 쓰기 명령을 실행한 후 AOF 파일 버퍼에 기록하여 후속 "쓰기" 명령을 실행합니다. 성능은 가장 좋지만 많은 데이터가 손실될 수 있습니다. 🎜🎜🎜65 형: 그러면 전략은 어떻게 선택해야 하나요? 🎜

고성능 및 높은 신뢰성에 대한 시스템 요구 사항에 따라 쓰기 저장 전략을 선택할 수 있습니다. 요약하자면, 높은 성능을 얻으려면 No 전략을 선택하고, 높은 신뢰성을 보장하려면 Always 전략을 선택하고, 약간의 데이터 손실을 허용하지만 성능에 큰 영향을 미치기를 원한다면 Everysec 전략을 선택하십시오. .

장점과 단점

장점: 성공적인 실행 후에만 로그가 기록되므로 명령어 구문 검사에 따른 오버헤드가 발생하지 않습니다. 동시에 현재 "쓰기" 명령은 차단되지 않습니다.

단점: AOF는 각 명령어의 내용을 기록하므로 구체적인 형식은 위의 로그 형식을 참조하세요. 오류 복구 중에 모든 명령을 실행해야 합니다. 로그 파일이 너무 크면 전체 복구 프로세스가 매우 느려집니다.

또한 파일 시스템에도 파일 크기 제한이 있습니다. 너무 큰 파일은 저장할 수 없습니다. 파일이 커질수록 추가 효율성도 낮아집니다.

로그가 너무 큽니다: AOF 다시 쓰기 메커니즘

65 형제: AOF 로그 파일이 너무 크면 어떻게 해야 하나요?

AOF 사전 쓰기 로그는 각 "쓰기" 명령 작업을 기록합니다. RDB 전체 스냅샷과 같은 성능 손실은 발생하지 않지만 실행 속도는 RDB만큼 빠르지 않습니다. 동시에 너무 큰 로그 파일은 속도만 원하는 Redis와 같은 실제 사람에게는 성능 문제를 일으킬 수도 있습니다. 그는 너무 큰 로그로 인해 발생하는 문제를 절대 용납할 수 없습니다.

그래서 Redis는 킬러 "AOF 재작성 메커니즘"을 설계했습니다. Redis는 AOF 로그를 줄이기 위한 bgrewriteaof 명령을 제공합니다.

원칙은 하위 프로세스를 열어 메모리를 순회하고 이를 일련의 Redis 작업 지침으로 변환하여 새로운 AOF 로그 파일로 직렬화하는 것입니다. 직렬화가 완료되면 작업 중 발생한 증분 AOF 로그가 새 AOF 로그 파일에 추가되며, 추가가 완료되면 기존 AOF 로그 파일이 즉시 교체되어 슬리밍 작업이 완료됩니다.

65 Brother: AOF 다시 쓰기 메커니즘이 로그 파일을 축소할 수 있는 이유는 무엇입니까?

재작성 메커니즘에는 재작성 후 이전 로그의 여러 명령을 하나의 명령으로 바꾸는 "다중 일" 기능이 있습니다.

아래와 같이:

3개의 LPUSH 명령어는 AOF로 다시 작성한 후 생성됩니다. 여러 번 수정된 장면의 경우 감소 효과가 더 분명합니다.

65 Brother: 다시 쓴 후 AOF 로그가 작아지고 마침내 전체 데이터베이스의 최신 데이터에 대한 작업 로그가 디스크에 플러시되었습니다. 다시 작성하면 메인 스레드가 차단되나요?

"Brother Ma"는 AOF 로그가 메인 스레드에 의해 다시 기록된다고 언급했습니다. AOF 재작성 프로세스는 메인 스레드 차단을 방지하기 위해 실제로 백그라운드 하위 프로세스 bgrewriteaof에 의해 완료됩니다.

재작성 프로세스

는 메인 스레드에 의해 다시 작성되는 AOF 로그와 다릅니다. 이는 또한 메인 스레드를 차단하고 데이터베이스 성능을 저하시키는 것을 방지하기 위한 것입니다. 감소하다.

일반적으로 총 2개의 로그, 하나의 메모리 데이터 복사본, 즉 이전 AOF 로그, 새로운 AOF 재작성 로그 및 Redis 데이터 복사본이 있습니다.

Redis는 재작성 프로세스 중에 수신된 "쓰기" 명령 작업을 이전 AOF 버퍼와 AOF 재작성 버퍼에 동시에 기록하므로 재작성 로그에도 최신 작업이 저장됩니다. 복사된 데이터의 모든 작업 기록을 다시 쓴 후 다시 쓰기 버퍼에 기록된 최신 작업도 새 AOF 파일에 기록됩니다.

AOF가 다시 작성될 때마다 Redis는 먼저 메모리 복사를 수행하여 데이터를 탐색하여 다시 쓰기 레코드를 생성합니다. 두 개의 로그를 사용하여 다시 쓰기 프로세스 중에 새로 작성된 데이터가 손실되지 않고 데이터가 일관되게 유지되는지 확인합니다. .

65 Brother: AOF rewrite에는 왜 AOF 자체를 사용하여 로그를 공유하지 않습니까?

이 질문은 다음 두 가지 이유로 좋은 질문입니다.

• 한 가지 이유는 상위 프로세스와 하위 프로세스가 동일한 파일을 작성할 때 필연적으로 경쟁이 발생한다는 것입니다. 경쟁을 제어한다는 것은 상위 프로세스의 성능에 영향을 미친다는 것을 의미합니다. .

• AOF 다시 쓰기 프로세스가 실패하면 원본 AOF 파일은 오염된 것과 동일하므로 복원 및 사용할 수 없습니다. 따라서 Redis AOF는 새 파일을 다시 작성합니다. 다시 작성하지 못한 경우에는 파일을 직접 삭제하면 됩니다. 원본 AOF 파일에는 영향을 미치지 않습니다. 재작성이 완료되면 기존 파일을 교체하면 됩니다.

Redis 4.0 하이브리드 로그 모델

Redis를 다시 시작할 때 많은 데이터가 손실되므로 메모리 상태를 복원하기 위해 rdb를 거의 사용하지 않습니다. 우리는 주로 AOF 로그 재생을 사용하는데, AOF 로그 재생의 성능은 RDB에 비해 훨씬 느리기 때문에 Redis 인스턴스가 클 경우 시작하는 데 시간이 오래 걸립니다.

Redis 4.0은 이 문제를 해결하기 위한 새로운 지속성 옵션인 하이브리드 지속성을 제공합니다. 증분 AOF 로그 파일과 함께 rdb 파일의 내용을 저장합니다. 여기서 AOF 로그는 더 이상 전체 로그가 아니라 지속성 시작부터 지속성 종료까지의 기간 동안 발생한 증분 AOF 로그입니다. 일반적으로 AOF 로그의 이 부분은 매우 작습니다.

그래서 Redis가 다시 시작되면 먼저 rdb 콘텐츠를 로드한 다음 증분 AOF 로그를 재생할 수 있습니다. 이는 이전 AOF 전체 파일 재생을 완전히 대체할 수 있어 다시 시작 효율성이 크게 향상됩니다.

따라서 RDB 메모리 스냅샷은 약간 느린 빈도로 실행되며, AOF 로깅을 사용하여 두 RDB 스냅샷 중에 발생한 모든 "쓰기" 작업을 기록합니다.

이렇게 하면 스냅샷을 자주 실행할 필요가 없습니다. 동시에 AOF는 두 스냅샷 사이에 발생하는 "쓰기" 명령만 기록하면 되므로 과도한 파일 크기를 피하기 위해 모든 작업을 기록할 필요가 없습니다. .

요약

Redis는 스냅샷 실행 중 읽기 및 쓰기 명령에 대한 영향을 최대한 방지하기 위해 bgsave 및 쓰기 시 복사를 설계했습니다. 빈번한 스냅샷은 디스크에 부담을 주고 포크는 기본 스레드를 차단합니다.

Redis는 데이터 손실 없이 가동 중지 시간을 빠르게 복구할 수 있는 두 가지 주요 킬러 기능을 설계했습니다.

로그가 너무 커지는 것을 방지하기 위해 데이터베이스의 최신 데이터 상태에 따라 데이터 쓰기 작업이 새 로그로 생성되고 메인 스레드를 차단하지 않고 백그라운드에서 완료되는 AOF 다시 쓰기 메커니즘이 제공됩니다. .

AOF와 RDB를 통합하면 Redis 4.0에서 새로운 지속성 전략과 하이브리드 로그 모델이 제공됩니다. Redis가 다시 시작되면 먼저 rdb 콘텐츠를 로드한 다음 증분 AOF 로그를 재생할 수 있습니다. 이는 이전 AOF 전체 파일 재생을 완전히 대체할 수 있으며 다시 시작 효율성이 크게 향상됩니다.

마지막으로 AOF와 RDB의 선택과 관련하여 "Code Byte"에는 세 가지 제안이 있습니다.

• 데이터가 손실될 수 없는 경우 메모리 스냅샷과 AOF를 혼합하여 사용하는 것이 좋습니다.
• 분 수준이 허용되는 경우; 데이터가 손실된 경우 RDB만 사용할 수 있습니다.
• AOF만 사용하는 경우 신뢰성과 성능 간의 균형을 유지하므로 Everysec 구성 옵션을 우선적으로 사용하세요.

조심하세요...

원본 주소: https://juejin.cn/post/6961735998547951653

저자: Code Brother Byte

더 많은 프로그래밍 관련 지식을 보려면 다음을 방문하세요: 프로그래밍 비디오! !

위 내용은 Redis에서 다운타임에 대한 두려움 없이 빠른 복구와 지속성을 달성하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!