Redis에서 캐시 정리 정책을 구성하는 위치

Redis를 캐시로 사용할 때 메모리 공간이 가득 차면 오래된 데이터가 자동으로 제거됩니다. Memcached는 기본적으로 이러한 방식으로 작동하며 대부분의 개발자는 이에 익숙합니다. (추천 학습: Redis 동영상 튜토리얼)

LRU는 Redis에서 지원하는 유일한 재활용 알고리즘입니다. 이 글에서는 최대 메모리 사용량을 제한하는 데 사용되는 maxmemory 명령어를 자세히 소개하고 대략적인 LRU 알고리즘에 대한 심층적인 설명을 제공합니다. Redis에서 사용됩니다.

maxmemory 구성 지시어

maxmemory는 Redis가 사용할 수 있는 최대 메모리를 지정하는 데 사용됩니다. redis.conf 파일에서 설정하거나 CONFIG SET 명령을 통해 작업 중에 동적으로 수정할 수 있습니다.

예를 들어 메모리 제한을 100MB로 설정하려면 redis.conf 파일에서 다음과 같이 구성할 수 있습니다.

maxmemory 100mb

maxmemory를 0으로 설정하면 메모리 제한이 없음을 의미합니다. 물론 32비트 시스템에는 최대 3GB RAM이라는 암묵적인 제한이 있습니다.

메모리 사용량이 최대 한도에 도달한 경우, 새로운 데이터를 저장해야 하는 경우 구성된 정책에 따라 Redis는 직접 오류 메시지를 반환하거나 일부 오래된 데이터를 삭제할 수 있습니다.

제거 정책

최대 메모리 제한(maxmemory)에 도달하면 Redis는 maxmemory-policy로 구성된 정책에 따라 특정 동작을 결정합니다.

현재 버전에서 Redis 3.0에서 지원하는 전략은 다음과 같습니다.

noeviction: 삭제 전략이 없습니다. 최대 메모리 제한에 도달했을 때 더 많은 메모리가 필요한 경우 오류 메시지가 직접 반환됩니다. 대부분의 쓰기 명령은 더 많은 메모리를 차지하게 합니다(DEL과 같은 드문 예외는 제외).

allkeys-lru: 모든 키에 공통되며 가장 최근에 사용된(LRU) 키를 먼저 삭제합니다.

휘발성-lru: 만료가 설정된 부분만 가장 최근에 사용된(LRU) 키를 먼저 삭제합니다.

allkeys-random: 모든 키에 공통되며 일부 키를 무작위로 삭제합니다.

휘발성-random: 만료가 설정된 부분으로만 제한되며 일부 키를 무작위로 삭제합니다.

휘발성-ttl: 만료가 설정된 부분으로만 제한되며, 남은 시간(Time to Live, TTL)이 짧은 키가 먼저 삭제됩니다.

만료 키가 설정되지 않고 전제 조건이 충족되지 않으면 휘발성-lru, 휘발성-랜덤 및 휘발성-ttl 전략의 동작은 기본적으로 noeviction(삭제 없음)과 동일합니다.

시스템의 특성에 따라 적절한 퇴거 전략을 선택해야 합니다. 물론, 동작 중 명령어를 통해 Eviction 정책을 동적으로 설정할 수도 있고, 튜닝을 위한 INFO 명령어를 통해 캐시 미스, 적중을 모니터링할 수도 있습니다.

일반적으로 말하면:

핫 데이터와 콜드 데이터로 나누어진다면 allkeys-lru 전략을 사용하는 것이 좋습니다. 즉, 특정 비즈니스 특성이 확실하지 않은 경우 일부 키를 자주 읽고 쓰는 경우 allkeys-lru가 좋은 선택입니다.

루프에서 모든 키를 읽고 써야 하거나 각 키의 액세스 빈도가 비슷한 경우 allkeys-random 전략을 사용할 수 있습니다. 즉, 모든 요소를 ​​읽고 쓸 확률이 거의 동일합니다.

Redis가 TTL을 기준으로 삭제해야 하는 키를 필터링하도록 하려면 휘발성-ttl 전략을 사용하세요.

휘발성-lru 및 휘발성-랜덤 전략의 주요 적용 시나리오는 캐시 키와 영구 키가 모두 있는 인스턴스입니다. 일반적으로 이와 같은 시나리오의 경우 두 개의 별도 Redis 인스턴스를 사용해야 합니다.

만료를 설정하면 추가 메모리가 소비된다는 점을 언급할 가치가 있습니다. 따라서 allkeys-lru 전략을 사용하면 만료 시간을 더 이상 설정할 수 없기 때문에 메모리를 더 효율적으로 사용할 수 있습니다.

제거의 내부 구현

제거 프로세스는 다음과 같이 이해할 수 있습니다.

클라이언트는 명령을 실행하여 Redis의 데이터가 증가하고 더 많은 메모리를 차지하게 됩니다.

Redis는 메모리 사용량을 확인합니다. 최대 메모리 제한을 초과하면 정책에 따라 일부 키가 지워집니다.

계속해서 다음 명령을 실행합니다.

이 과정에서 메모리 사용량은 계속해서 제한 값에 도달했다가 이를 초과한 다음 일부 키를 삭제하고 사용량이 다시 제한 값 아래로 떨어집니다.

특정 명령으로 인해 대량의 메모리 사용량이 발생하는 경우(예: 새 키를 통해 큰 세트 저장) 메모리 사용량이 일정 기간 동안 최대 메모리 제한을 크게 초과할 수 있습니다.

대략적인 LRU 알고리즘

Redis는 완전한 LRU 알고리즘을 사용하지 않습니다. 자동으로 제거되는 키는 반드시 LRU 특성을 가장 잘 만족하는 키는 아니며, 대신 근사 LRU 알고리즘을 통해 소수의 키 샘플을 추출한 후, 접근 시간이 가장 오래된 키를 삭제합니다.

제거 알고리즘은 Redis 3.0부터 풀을 후보로 사용하여 크게 최적화되었습니다. 이는 알고리즘 효율성을 크게 향상시키고 실제 LRU 알고리즘에 더 가깝습니다.

Redis의 LRU 알고리즘에서는 샘플 수를 설정하여 알고리즘의 정확도를 조정할 수 있습니다. 다음 명령을 통해 구성하십시오.

maxmemory-samples 5

전체 LRU 구현을 사용하지 않는 이유는 메모리를 절약하기 위한 것입니다. 그러나 Redis의 동작은 기본적으로 LRU와 동일합니다. 다음은 Redis LRU와 전체 LRU 알고리즘 간의 동작 비교 차트입니다.

테스트 과정에서는 첫 번째 키부터 접근이 시작되므로 첫 번째 키가 가장 좋은 퇴거 대상입니다.

사진에서 세 가지 유형의 점이 세 가지 다른 스트립을 형성하는 것을 볼 수 있습니다.

밝은 회색 부분은 퇴거된 개체를 나타냅니다.

회색 부분은 "퇴거되지 않은" 개체를 나타냅니다.

녹색 부분은 나중에 추가된 개체를 나타냅니다.

순수한 LRU 알고리즘 구현에서는 이전 키의 전반부가 공개됩니다. Redis의 LRU 알고리즘은 확률적으로 더 긴 키만 해제합니다.

보시다시피 Redis 3.0에서는 Redis 2.8보다 5개 샘플의 효과가 훨씬 좋습니다. 물론 Redis 2.8도 좋습니다. 마지막으로 액세스한 키는 기본적으로 여전히 메모리에 남아 있습니다. Redis 3.0에서 10개의 샘플을 사용하면 순수 LRU 알고리즘에 매우 가깝습니다.

LRU는 특정 키가 앞으로도 계속 액세스될 수 있음을 예측하는 데 사용되는 확률 모델일 뿐입니다. 또한 데이터 액세스 상황이 거듭제곱 법칙 분포를 준수하면 대부분의 요청에 대해 LRU가 좋은 성능을 발휘합니다. .

시뮬레이션에서 우리는 거듭제곱 법칙 액세스를 사용하면 순수 LRU와 Redis의 결과가 매우 다르거나 심지어 눈에 띄지 않는다는 것을 발견했습니다.

물론 CPU를 추가로 소모하여 샘플 수를 10개로 늘려 실제 LRU에 가까운 결과를 만들고 캐시 미스 통계를 통해 차이를 판단할 수도 있습니다.

샘플 크기를 설정하는 것은 쉽습니다. CONFIG SET maxmemory-samples 명령을 사용하세요.

더 많은 Redis 관련 기술 기사를 보려면 Redis 시작 튜토리얼 열을 방문하세요.

위 내용은 Redis에서 캐시 정리 정책을 구성하는 위치의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!