Redis가 다운되면 어떻게 해야 하나요?

우리 모두는 모든 Redis 데이터가 메모리에 있다는 것을 알고 있습니다. 갑작스런 다운타임이 발생하면 모든 데이터가 손실됩니다. 그렇다면 어떻게 해결해야 할까요?

따라서 Redis 데이터가 오류로 인해 손실되지 않도록 보장하는 메커니즘이 있어야 합니다. 이 메커니즘이 Redis의 지속성 메커니즘입니다. (추천 학습: Redis 동영상 튜토리얼)

Redis에는 두 가지 지속성 메커니즘이 있는데, 첫 번째는 스냅샷이고 두 번째는 AOF 로그입니다. 스냅샷은 전체 백업이고 AOF 로그는 지속적인 증분 백업입니다. 스냅샷은 메모리 데이터의 이진 직렬화된 형식이며 저장 공간이 매우 컴팩트한 반면, AOF 로그는 메모리 데이터 수정에 대한 명령 기록 텍스트를 기록합니다. AOF 로그는 장기간 작업 중에 매우 커집니다. 데이터베이스를 다시 시작하면 명령 재생을 위해 AOF 로그를 로드해야 하므로 시간이 매우 오래 걸립니다. 따라서 AOF 로그를 정기적으로 다시 작성하여 용량을 줄여야 합니다. AOF 로그.

스냅샷 원리

우리는 Redis가 단일 스레드 프로그램이라는 것을 알고 있습니다. 이 스레드는 여러 클라이언트 소켓의 동시 읽기 및 쓰기 작업과 메모리 데이터 구조의 논리적 읽기 및 쓰기를 담당합니다.

서비스 라인에서 요청하는 동안 Redis는 메모리 스냅샷도 수행해야 합니다. 메모리 스냅샷을 위해서는 Redis가 파일 IO 작업을 수행해야 하지만 파일 IO 작업은 멀티플렉싱 API를 사용할 수 없습니다.
이는 단일 스레드가 서비스 라인에서 요청하는 동안 파일 IO 작업도 수행해야 하며 파일 IO 작업이 서버 요청 성능을 심각하게 저하시킨다는 것을 의미합니다.

온라인 비즈니스를 막지 않기 위해서는 Redis가 클라이언트 요청에 응답하면서 지속되어야 하는 또 다른 중요한 문제가 있습니다. 지속되는 동안 메모리 데이터 구조는 계속 변경됩니다. 예를 들어, 대규모 해시 사전이 지속되고 있는데 요청이 와서 이를 삭제했지만 아직 지속되지 않았습니다. 어떻게 해야 합니까?

Redis는 운영 체제의 다중 프로세스 COW(Copy On Write) 메커니즘을 사용하여 스냅샷 지속성을 달성합니다. 이 메커니즘은 매우 흥미롭고 이를 아는 사람은 거의 없습니다.

AOF 원칙

AOF 로그는 Redis 서버의 순차적 명령 시퀀스를 저장합니다. AOF 로그는 메모리를 수정하는 명령만 기록합니다.

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

Redis는 클라이언트 수정 명령을 받은 후 매개변수 확인 및 논리 처리를 수행합니다. 문제가 없으면 명령 텍스트를 즉시 AOF 로그에 저장합니다. 즉, 로그가 저장되기 전에 명령이 먼저 실행됩니다. . 이는 로그를 먼저 저장한 후 논리적 처리를 수행하는 leveldb, hbase 등의 스토리지 엔진과 다릅니다.

Redis를 장기간 운영하는 동안 AOF 로그는 점점 길어질 것입니다. 인스턴스가 충돌하고 다시 시작되면 전체 AOF 로그를 재생하는 데 시간이 많이 걸리므로 Redis가 오랫동안 외부 서비스를 제공할 수 없게 됩니다. 따라서 AOF 로그를 줄여야 합니다.

Redis 관련 기술 기사를 더 보려면 Redis 데이터베이스 사용 튜토리얼 소개 칼럼을 방문하여 알아보세요!

위 내용은 Redis가 다운되면 어떻게 해야 하나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!