Redis는 현재 웹 프로그래밍에 없어서는 안될 서비스입니다. memcached와 비교하면 데이터 손실 없이 캐시하고 다시 시작할 수 있어 사용이 매우 쉽습니다. 그래서 질문은 어떻게 하는가 입니다.
RDB
RDB는 특정 조건에서 메모리의 데이터를 디스크에 쓰는 지속성 수단입니다. 그럼 어떤 조건에서 쓰여졌나요? 생각 없이 쓰는 것은 불가능합니다. 하나하나 쓰다 보면 성능에 영향을 미치게 됩니다. 한참을 기다리다가 중간에 컴퓨터가 다운되어 모든 데이터를 잃어버리게 됩니다. memcached를 사용하는 것이 더 좋습니다. Redis 구성에는 다음과 같은 구성이 있습니다.
save 900 1
save 300 10
save 60 10000
RDB 지속성의 핵심인 매우 중요한 구성입니다. 의미:
1. 900초 안에 1개의 키가 변경(삽입 또는 업데이트)되면 디스크에 동기화합니다.
2 300초 안에 10개의 키가 변경(삽입 또는 업데이트)되면 디스크에 동기화됩니다. 디스크
3. 60초 안에 10,000개의 키가 변경(삽입 또는 업데이트)되면 디스크에 동기화합니다
이 시점과 변경 횟수를 어떻게 알 수 있나요? 중요한 것은 더티 카운터(dirty counter)와 마지막 저장 시간(lastsave)이라고 합니다. 더티 카운터는 마지막 저장 이후 변경된 키 수를 구체적으로 기록합니다. 예를 들어 저장이 실행되는 시간입니다. 는 time1, dirty는 0입니다. 이때 20개의 키가 변경되었고 dirty는 20이며 현재 시간은 time2, time2-time1 ≥= 300, 두 번째 조건이 충족되어 메모리의 데이터는 일단 더티가 0으로 지워진 다음 조건이 트리거될 때까지 기다립니다.
60초에 100,000개의 키가 있으면 문제가 발생합니다. 대량의 디스크 IO가 발생하고 redis 메인 프로세스가 차단되고 해당 기간 동안의 모든 명령이 실행되지 않습니다. , 그래서 여기에 bgsave라는 프로그램을 만들었습니다. 이 프로그램은 기본 Redis 프로세스에서 분기된 하위 프로세스이며 RDB 지속성을 수행하도록 특별히 설계되었습니다.
저장된 파일 형식은 바이너리 형식입니다. 데이터베이스가 다운되면 복구를 위해 사람의 개입이 필요하지 않으며 Redis가 자동으로 디스크 파일을 읽습니다.
AOF
RDB와 달리 AOF는 aof 기능이 활성화되면 실행된 업데이트 명령이 aof 파일에 직접 기록되지 않고 먼저 aof buf에 기록됩니다. 우리는 항상 buf에 쓸 수는 없다는 것을 알고 있습니다. buf도 메모리이므로 언제 디스크에 동기화할 수 있습니까? redis
appendfsync Always
appendfsync Everysec
appendfsync no
에는 다음과 같은 구성이 있습니다.
1 업데이트된 명령이 있는 한 동기화합니다
2. 지금부터 1초 이상 동기화
3. 동기화되지 않고 운영체제가 스스로 판단하기를 기다립니다(한가할 때 동기화하겠습니다)
분석에 따르면 첫 번째 유형의 io가 자주 발생하고 io 압력이 발생합니다. 두 번째 유형의 IO 압력은 크지 않으며 최대 1초 정도의 데이터만 손실되며, 데이터 손실 확률은 매우 낮습니다. 너무 높다. 모든 것을 고려하면 일반적으로 두 번째 옵션입니다. 하지만 여전히 문제가 있습니다. INCR num을 100번 실행했는데 논리적으로 num은 100입니다. aof에 동일한 명령이 100개 있는데 INCR num 100번 실행과 SET num 100 실행의 차이점은 무엇입니까? ? 같은 결과입니다. 전자는 99배의 공간을 차지하므로 매우 낭비적이므로 AOF 재작성은 어떻게 이루어지나요? 매우 간단합니다. 먼저 데이터베이스에서 현재 값을 읽은 다음 이를 레코드로 대체하는 것이 AOF 재작성의 원칙입니다. 다시 작성하는 데 시간이 걸리므로 하위 프로세스에서 처리됩니다. 재작성 과정에서 새로운 명령이 오면 어떻게 해야 하나요? 기존 방법은 재작성이 완료된 후 buf에 있는 명령을 새로운 aof에 추가하는 것입니다. 새로운 aof를 구현했습니다.
이 기사는 redis 튜토리얼에서 가져온 것입니다. 학습을 환영합니다.
위 내용은 Redis에서 지속성을 달성하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!