Redis 메모리가 너무 크면 어떻게 되나요?

1 메인 데이터베이스가 다운되었습니다

먼저 메인 데이터베이스 다운타임 재해 복구 프로세스를 살펴보겠습니다. 아래와 같이

메인 데이터베이스가 다운되면 가장 일반적인 재해 복구 전략은 " 주인". 구체적으로는 클러스터의 나머지 슬레이브 라이브러리 중에서 슬레이브 라이브러리를 선택하여 마스터 라이브러리로 업그레이드합니다. 슬레이브 라이브러리가 마스터 라이브러리로 업그레이드된 후 나머지 슬레이브 라이브러리가 그 아래에 마운트되어 슬레이브 라이브러리가 됩니다. 전체 마스터-슬레이브 데이터베이스가 복원됩니다.

위는 완전한 재해 복구 프로세스이며, 가장 비용이 많이 드는 프로세스는 메인 라이브러리 전환이 아닌 슬레이브 라이브러리를 다시 마운트하는 것입니다.

mysql 및 mongodb와 같은 동기화 지점을 기반으로 기본 데이터베이스가 변경된 후에는 redis가 새 기본 데이터베이스의 데이터를 계속 동기화할 수 없기 때문입니다. 슬레이브 데이터베이스가 Redis 클러스터에서 마스터를 변경하면 Redis의 접근 방식은 교체된 마스터 데이터베이스의 슬레이브 데이터베이스를 지운 다음 전송을 재개하기 전에 새 마스터 데이터베이스의 데이터 복사본을 완전히 동기화하는 것입니다.

전체 슬레이브 라이브러리 재실행 프로세스는 다음과 같습니다.

1. 메인 라이브러리 bgs는 자체 데이터를 디스크에 저장합니다

2. 메인 라이브러리는 rdb 파일을 슬레이브 라이브러리로 보냅니다

3. 라이브러리에서 로딩 시작

4. 로드 후 시작 다운로드 재개와 동시에 서비스 제공 시작

분명히 이 과정에서 Redis의 메모리 크기가 커질수록 위의 각 단계에 소요되는 시간은 실제로 길어집니다. 테스트 데이터는 다음과 같습니다(저희 머신 성능이 더 좋다고 믿습니다).

데이터가 20G에 도달하면 슬레이브 데이터베이스의 복구 시간이 10분이면 거의 20분으로 연장되는 것을 볼 수 있습니다. 슬레이브 데이터베이스를 순차적으로 복원하는 데 총 200분이 소요되며, 이때 슬레이브 라이브러리가 대량의 읽기 요청을 담당하고 있다면 이렇게 긴 복구 시간을 견딜 수 있습니까?

이것을 보면 확실히 그럴 것입니다. 질문: 모든 슬레이브 라이브러리를 동시에 다시 실행할 수 없는 이유는 모든 슬레이브 라이브러리가 동시에 다시 실행될 경우 메인 라이브러리에서 RDB 파일을 요청하면 메인 라이브러리의 네트워크 카드가 즉시 가득 차기 때문입니다. 이때, 본관 도서관이 또 죽게 되면서 치욕만 가중될 뿐입니다.

물론 슬레이브 데이터베이스를 일괄적으로 복원할 수 있습니다(예: 2개 그룹). 그러면 모든 슬레이브 데이터베이스의 복구 시간이 200분에서 100분으로 단축됩니다. 이것은 단지 50단계와 문제가 아니겠습니까?

또 다른 중요한 질문 네 번째 지점의 빨간색 위치는 재개 전송을 단순화된 mongodb oplog로 이해할 수 있습니다. 이는 "동기화 버퍼"라고 부르는 고정된 볼륨을 갖는 메모리 공간입니다.

redis 메인 라이브러리의 쓰기 작업이 이 영역에 저장된 후 슬레이브 라이브러리로 전송됩니다. 위의 1, 2, 3단계가 너무 오래 걸리면 동기화 버퍼를 덮어쓸 가능성이 높습니다. 슬레이브 라이브러리가 해당 재개 위치를 찾을 수 없으면 1, 2, 3단계를 다시 실행하는 것이 답입니다.

하지만 시간이 많이 걸리는 1, 2, 3단계를 해결할 수 없기 때문에 슬레이브 라이브러리는 악순환: 지속적으로 메인 데이터베이스에 완전한 데이터를 요청하여 메인 데이터베이스의 네트워크 카드에 심각한 영향을 미칩니다.

2 용량 확장 문제

갑작스런 트래픽 증가가 발생하는 경우가 많습니다. 일반적으로 원인을 찾기 전에 긴급 대응은 용량 확장입니다.

시나리오 1의 표에 따르면 20G Redis 슬레이브 데이터베이스를 확장하는 데 거의 20분이 소요됩니다. 이 중요한 순간에 20분의 비즈니스가 확장이 완료되기 전에 중단될 수 있습니까?

3 네트워크 불량은 슬레이브 라이브러리 재실행으로 이어져 결국 산사태를 유발합니다

이 시나리오의 가장 큰 문제는 마스터 라이브러리와 슬레이브 라이브러리 간의 동기화가 중단된다는 점이며, 이때 슬레이브 라이브러리가 여전히 쓰기 요청을 승인하고 있는 경우, 중단 시간이 너무 길어지면 동기화 버퍼를 덮어쓸 가능성이 높습니다. 이때 슬레이브 라이브러리의 마지막 동기화 위치가 손실되었습니다. 네트워크가 복원된 후 마스터 라이브러리는 변경되지 않았지만 슬레이브 라이브러리의 동기화 위치가 손실되었기 때문에 슬레이브 라이브러리를 다시 수행해야 합니다. 문제 1의 1, 2, 3. 4단계. 이때 메인 라이브러리의 메모리 크기가 너무 크면 슬레이브 라이브러리의 다시 실행 속도가 매우 느려지고 동시에 슬레이브 라이브러리의 크기가 심각하게 영향을 받습니다. 전송된 RDB 파일이 너무 크면 메인 라이브러리의 네트워크 카드가 오랫동안 심각한 영향을 받게 됩니다.

4 메모리가 클수록 지속성을 트리거하는 작업이 길어지면 기본 스레드가 차단됩니다.

Redis는 단일 스레드 메모리 내 데이터베이스로, 시간이 많이 걸리는 작업을 수행해야 할 경우 새 스레드를 포크합니다. bgsave, bgrewriteaof와 같은 프로세스를 수행합니다. 새 프로세스를 포크할 때 공유 가능한 데이터 내용을 복사할 필요는 없지만 이전 프로세스 공간의 메모리 페이지 테이블이 복사됩니다. 이 복사는 기본 스레드에 의해 수행되며 모든 읽기 및 쓰기 작업을 차단합니다. 메모리 사용량이 증가할수록 시간이 오래 걸립니다. 예를 들어, 메모리가 20G인 Redis의 경우 bgsave는 메모리 페이지 테이블을 복사하는 데 약 750ms가 걸리며 Redis 기본 스레드도 750ms 동안 차단됩니다.

해결책

물론 일반적인 상황에서는 다음과 같이 메모리 사용량을 줄이는 것이 해결책입니다.

1 만료 시간 설정

시간에 민감한 키의 만료 시간 설정. . Redis만의 만료된 키 정리 전략으로 만료된 키의 메모리 사용량을 줄일 수 있으며, 정기적으로 정리할 필요도 없습니다.

2 Redis에 쓰레기를 저장하지 마세요

말도 안 되는 소리지만, 혹시 우리와 같은 생각을 하는 사람이 있을까?

3 쓸모없는 데이터를 제때에 정리한다

예를 들어 Redis는 3개 기업의 데이터를 담고 일정 시간이 지나면 2개 기업의 데이터를 가져온다. 그런 다음 이 두 업체의 관련 데이터만 정리하세요

4 데이터를 최대한 압축해 보세요

예를 들어 일부 긴 텍스트 데이터의 경우 압축하면 메모리 사용량이 크게 줄어들 수 있습니다

5 유료 메모리 증가에 주의하고 대용량 키 찾기

DBA이든 개발자이든 Redis를 사용한다면 메모리에 주의해야 합니다. 그렇지 않으면 실제로 Redis에 어떤 키가 있는지 분석할 수 있습니다. 인스턴스는 비즈니스가 비정상적인 키를 신속하게 찾는 데 도움이 되도록 상대적으로 큽니다(키가 커질 것으로 예상되는 키가 아닌 것이 문제의 원인이 되는 경우가 많습니다)

6 pika

정말 피곤하고 싶지 않다면 마이그레이션하세요. 비즈니스에서는 새로운 오픈소스 피카를 사용하므로 메모리에 너무 많은 관심을 기울이지 않아도 되므로 Redis 메모리도 이로 인해 발생하는 문제는 더 이상 문제가 되지 않습니다.

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