Redis 핵심 포인트 분석

1. 소개

원격 사전 서비스인 Redis(Remote Dictionary Server)는 ANSI C 언어로 작성된 오픈소스 로그형 Key-Value 데이터베이스로 네트워크를 지원하며 메모리 기반 또는 지속성 그리고 여러 언어로 API를 제공합니다.

(학습 영상 공유: redis 영상 튜토리얼)

빠른 시작, 높은 실행 효율성, 다중 데이터 구조, 지속성 및 클러스터링 지원 및 기타 기능으로 인해 많은 인터넷 회사에서 사용됩니다. 그러나 부적절하게 사용하고 운영할 경우 메모리 낭비, 심지어 시스템 다운타임 등 심각한 결과를 초래할 수 있습니다.

2. 핵심 분석

2.1 올바른 데이터 유형을 사용하세요

Redis의 5가지 데이터 유형 중 문자열 유형이 가장 일반적으로 사용되고 간단합니다. 그러나 문제를 해결할 수 있다고 해서 올바른 데이터 유형을 사용하고 있다는 의미는 아닙니다.

예를 들어 사용자(이름, 나이, 도시) 정보를 Redis에 저장하려면 아래 세 가지 옵션이 있습니다.

옵션 1: 문자열 유형을 사용하고 각 속성은 키로 처리됩니다.

set user:1:name laowang
set user:1:age 40
set user:1:city shanghai

장점: 간단하고 직관적입니다. ,ever 각 속성은 업데이트 작업을 지원합니다
단점: 너무 많은 키를 사용하고, 많은 양의 메모리를 차지하고, 사용자 정보 집계가 좋지 않아 관리 및 유지 관리가 번거롭습니다.

옵션 2: 문자열 유형을 사용하여 사용자 정보를 string 저장

// 序列化用户信息
String userInfo = serialize(user)
set user:1 userInfo

장점: 단순화된 저장 단계
단점: 직렬화 및 역직렬화에 특정 오버헤드가 있습니다

옵션 3: 해시 유형을 사용하고 각 속성에 대해 필드-값 쌍을 사용하지만 하나의 키만 사용

hmset user:1 name laowang age 40 city shanghai

장점 : 간단하고 직관적이며 합리적인 사용으로 메모리 공간을 줄일 수 있습니다

요약: Redis에서 키를 줄여보세요.

2.2 빅 키에 주의하세요

빅 키는 일반적으로 문자열 유형 값이 매우 큰 키(10KB 초과) 또는 해시, 목록, 집합 또는 순서가 지정된 집합 요소의 수가 많은 키(10KB 초과)를 나타냅니다. 5000).

큰 키는 Redis에 많은 부정적인 영향을 미칩니다.

불균일한 메모리: 클러스터 환경에서는 큰 키가 어떤 노드에 할당되고 노드가 차지하는 공간을 알 수 없기 때문에 특정 노드 머신에 할당됩니다. 대용량 메모리, 클러스터 환경에서 메모리 통합 관리에 도움이 되지 않습니다

타임아웃 차단: Redis는 단일 스레드 작업이므로 큰 키를 조작하는 데 시간이 많이 걸리고 쉽게 차단이 발생할 수 있습니다

만료된 삭제: 큰 키는 읽고 쓰는 속도가 느릴 뿐만 아니라 삭제하는 속도도 느리고, 만료된 큰 키를 삭제하는 데에도 시간이 더 많이 걸립니다.

마이그레이션이 어렵습니다. 데이터가 방대하기 때문에 백업 및 복원이 쉽습니다. 방해 및 작동 실패 유발

이제 큰 키의 위험성을 알았으니 어떻게 큰 키를 판단하고 쿼리할까요? 실제로 redis-cli는 --bigkeys 매개변수를 제공합니다. redis-cli --bigkeys를 입력하여 큰 키를 쿼리합니다.

큰 열쇠를 찾은 후, 우리는 보통 큰 열쇠를 여러 개의 작은 열쇠로 나누어 보관합니다. 이 접근 방식은 2.1의 요약과 모순되는 것처럼 보이지만 모든 솔루션에는 장점과 단점이 있으며 장단점의 무게는 실제 상황에 따라 다릅니다.

요약: Redis에서 큰 키를 줄여보세요.

추가: 특정 키가 차지하는 메모리 공간을 확인하려면 메모리 사용량 명령을 사용할 수 있습니다. 참고: 이 명령은 Redis 4.0 이상에서만 사용할 수 있습니다. 이 명령을 사용하려면 Redis를 4.0 이상으로 업그레이드해야 합니다.

2.3 메모리 소비

올바른 데이터 유형을 사용하여 데이터를 저장하고 Big Key를 작은 키로 분할하더라도 메모리 소비 문제는 계속 발생합니다. 그러면 Redis 메모리 소비는 어떻게 발생합니까? 일반적으로 다음 3가지 상황에 의해 발생합니다.

비즈니스가 계속 발전하고, 저장된 데이터가 계속 증가합니다(필연)

유효하지 않거나 만료된 데이터가 제때 처리되지 않습니다(최적화 가능).

Cold 데이터가 다운그레이드되지 않습니다(불가능). 최적화)

사례 2를 최적화하기 전에 만료된 데이터를 제때 처리하지 못하는 문제가 있는 이유를 먼저 알아야 합니다. 이는 Redis에서 제공하는 세 가지 만료된 삭제 전략과 관련이 있습니다.

예약 삭제: 각 키에 대해. 만료 시간이 설정된 경우 만료 시간에 도달하면 즉시 타이머가 생성되고 삭제됩니다

지연 삭제: 키에 액세스하면 키가 만료되었는지 판단하여 만료됩니다

정기적 삭제: 정기적으로 사전에 Redis에서 만료된 키를 스캔하고 일부 만료된 키를 지웁니다.

예약 삭제에는 타이머 생성이 필요하므로 많은 메모리를 차지하며 많은 수의 키를 정확하게 삭제하면 많은 CPU 리소스를 소비하므로 Redis는 지연 삭제와 예약 삭제 전략을 모두 사용합니다. 클라이언트가 만료된 키를 요청하지 않거나 일반 삭제 스레드가 키를 검색하고 지우지 않으면 키가 계속 메모리를 차지하여 메모리 낭비가 발생합니다.

메모리 소비의 원인을 파악한 후 신속하게 최적화 솔루션인 수동 삭제를 생각해 낼 수 있습니다.

캐시 사용 후 캐시에 만료 시간이 있더라도 수동으로 del 메소드/명령어를 호출하여 삭제해야 합니다. 즉시 삭제할 수 없는 경우 코드에서 타이머를 시작하여 만료된 키를 정기적으로 삭제할 수도 있습니다. Redis의 두 가지 삭제 전략과 비교할 때 수동 데이터 삭제가 훨씬 더 시기적절합니다.

3번 사례의 문제는 큰 문제가 아닙니다. 최적화를 위해 Redis 제거 전략을 조정할 수 있습니다.

2.4 여러 명령 실행

Redis는 하나의 요청과 하나의 응답을 기반으로 하는 동기식 요청 서비스입니다. 즉, 여러 클라이언트가 Redis 서버에 명령을 보내면 Redis 서버는 클라이언트 중 하나의 명령만 수신하고 처리할 수 있습니다. 다른 클라이언트는 수신을 계속하기 전에 Redis 서버가 현재 명령을 처리하고 응답할 때까지만 기다릴 수 있습니다. 다른 명령 요청을 처리합니다.

Redis는 명령 수신, 명령 처리, 결과 반환의 세 가지 프로세스로 명령을 처리합니다. 처리된 데이터는 모두 메모리에 있기 때문에 처리 시간은 일반적으로 나노초 수준으로 매우 빠릅니다(큰 키 제외). 따라서 시간이 많이 걸리는 상황은 대부분 명령을 수락하고 결과를 반환하는 과정에서 발생합니다. 클라이언트가 Redis 서버에 여러 명령을 보낼 때 하나의 명령을 처리하는 데 시간이 오래 걸리면 다른 명령은 대기만 할 수 있으므로 전체 성능에 영향을 미칩니다.

이런 종류의 문제를 해결하기 위해 Redis는 파이프라인에 여러 명령을 넣은 다음 Redis 서버가 처리를 완료한 후 파이프라인 명령을 Redis 서버로 한 번에 보낼 수 있는 기능을 제공합니다. 결과를 한 번에 클라이언트에게 전달합니다. 이 처리는 클라이언트와 Redis 서버 간의 상호 작용 횟수를 줄여 왕복 시간을 줄이고 성능을 향상시킵니다.

보충 사항:

Redis 파이프라인과 기본 배치 명령 간의 비교:

기본 배치 명령은 원자적이고 파이프라인은 비원자적입니다.

기본 배치 명령은 한 번에 하나의 명령만 실행할 수 있지만 파이프라인은 여러 명령 실행을 지원합니다.

네이티브 배치 명령은 서버 측에서 구현되며 파이프라인은 서버 측과 클라이언트에서 구현되어야 합니다.

Redis 파이프라인 사용 시 주의 사항:

파이프라인을 사용하여 로드되는 명령 수는 다음과 같습니다. too much

파이프라인의 명령은 버퍼링된 순서대로 실행되지만 그럴 수도 있습니다. 다른 클라이언트에서 보낸 명령이 흩어지게 되어 타이밍이 보장되지 않습니다

pipeline 명령 실행 중 예외가 발생하는 경우 후속 명령은 계속 실행됩니다. 즉, 원자성이 보장되지 않습니다.

2.5 캐시 침투

프로젝트에서 캐시를 사용하는 일반적인 디자인 아이디어는 다음과 같습니다.

데이터 쿼리 요청을 보냅니다. 쿼리 규칙은 먼저 캐시를 확인하고, 캐시에 데이터가 없으면 데이터베이스에 쿼리하여 찾은 데이터를 캐시에 넣고 마지막으로 데이터를 클라이언트에 반환하는 것입니다. 요청한 데이터가 존재하지 않으면 결국 각 요청이 데이터베이스에 요청되는데, 이는 캐시 침투입니다.

캐시 침투는 막대한 보안 위험을 초래합니다. 누군가가 도구를 사용하여 존재하지 않는 데이터에 대해 대량의 요청을 보내는 경우 대량의 요청이 데이터베이스로 유입되어 데이터베이스에 대한 부담이 증가하여 데이터베이스 문제가 발생할 수 있습니다. 다운타임은 전체 애플리케이션의 정상적인 작동에 영향을 미치고 시스템 마비로 이어집니다.

이러한 유형의 문제를 해결하기 위해 데이터베이스에 대한 액세스를 줄이는 데 중점을 둡니다. 일반적으로 다음과 같은 해결 방법이 있습니다.

캐시 예열: 시스템이 출시되고 온라인 상태가 된 후 관련 데이터가 사전에 캐시 시스템에 직접 로드됩니다.

기본값 설정: 요청이 마침내 데이터베이스에 도착하고 데이터베이스가 데이터를 찾을 수 없으면 캐시 키의 기본값을 설정하고 캐시에 넣습니다. 참고: 이 기본값은 의미가 없으므로 다음을 수행해야 합니다. 메모리 사용량을 줄이기 위해 만료 시간을 설정하세요

Bloom 필터: 가능한 모든 데이터를 충분히 큰 비트맵으로 해시합니다. 존재하지 않는 데이터는 확실히 비트맵에 의해 차단됩니다.

2.6 캐시 눈사태

캐시 눈사태: 간단히 말해서 캐시된 데이터에 대한 대량의 접근을 요청하지만 쿼리에 실패하여 데이터베이스를 요청하게 되면 데이터베이스에 대한 부담이 가중되고, 성능이 저하되며, 다운타임이 과도하게 발생하여 전체 시스템의 정상적인 운영에 영향을 미치고, 심지어는 시스템 마비.

예를 들어, 전체 시스템은 시스템 A, 시스템 B, 시스템 C의 세 가지 하위 시스템으로 구성됩니다. 해당 데이터 요청 체인은 시스템 A -> 시스템 B -> 데이터베이스입니다. 캐시에 데이터가 없고 데이터베이스가 다운된 경우 시스템 C는 데이터를 쿼리하고 응답할 수 없으며 재시도 대기 단계에만 있을 수 있으므로 시스템 B와 시스템 A에 영향을 미칩니다. 마치 눈 덮인 산에 돌풍이 불어 눈사태를 일으키는 것처럼 한 노드에 이상이 생기면 일련의 문제가 발생합니다.

이것을 보고 일부 독자들은 캐시 침투와 캐시 눈사태의 차이점이 무엇인지 궁금해할 수 있습니다.

캐시 침투는 요청한 데이터가 캐시에 없다는 점에 초점을 맞추므로 데이터베이스를 요청하는 것은 캐시를 통해 직접 데이터베이스를 요청하는 것과 같습니다.

캐시 사태는 대규모 요청에 초점을 맞춥니다. 캐시에서 데이터를 쿼리할 수 없기 때문에 데이터베이스에 액세스하면 데이터베이스에 대한 부담이 커지고 일련의 예외가 발생합니다.

캐시 눈사태 문제를 해결하려면 먼저 문제의 원인을 알아야 합니다.

Redis 자체에 문제가 있습니다.

핫스팟 데이터 세트가 실패합니다.

이유 1의 경우 마스터-슬레이브, 클러스터링, 모든 요청을 캐시에 보관하려고 합니다. 캐시에서 데이터를 찾아 데이터베이스에 대한 액세스를 줄이세요

이유 2의 경우, 캐시 만료 시간을 설정할 때 만료 시간에 시차를 두세요(예: 캐시에 임의의 값을 더하거나 빼는 등). 기본 시간) 중앙 집중식 캐시 오류를 방지합니다. 동시에 로컬 캐시(예: ehcache)를 설정하여 인터페이스 흐름을 제한하거나 서비스를 다운그레이드하여 데이터베이스에 대한 액세스 압력을 줄일 수도 있습니다.

🎜3. 참고자료🎜

Redis의 파이프라인 작업

Redis 애플리케이션-Bloom 필터

관련 권장 사항: redis 데이터베이스 튜토리얼

위 내용은 Redis 핵심 포인트 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!