간단히 말하면 특정 키에 해당하는 값이 매우 크고 Redis 공간을 많이 차지한다는 의미로 본질적으로 큰 값 문제입니다. 키는 프로그램 자체에서 설정할 수 있는 경우가 많고, 값은 프로그램에서 제어할 수 없는 경우가 많아 값이 매우 클 수 있습니다.
redis에서 이러한 Big Key에 해당하는 값은 매우 크고 직렬화/역직렬화 과정에서 많은 시간이 소요되므로 일반적으로 Big Key를 조작할 때 시간이 많이 걸리므로 Redis가 차단될 수 있습니다. . 따라서 Redis 성능이 저하됩니다.
몇 가지 실제 예를 사용하여 대형 키의 특성을 설명합니다.
● 문자열 유형의 키, 해당 값은 5MB(데이터가 너무 큼)
● 목록 유형의 키, 목록 수는 20,000개입니다. (목록이 너무 많음);
● 멤버가 10,000개인 ZSet 유형 키(멤버가 너무 많음)
● 멤버가 1,000명에 불과한 해시 형식 키이지만 이 멤버의 총 값 크기는 100MB입니다(멤버 크기가 너무 큼). );
실제 비즈니스에서는 대규모 키의 결정은 여전히 Redis의 실제 사용 시나리오와 비즈니스 시나리오를 기반으로 종합적으로 판단해야 합니다. 일반적으로 데이터의 크기와 구성원 수로 판단됩니다.
1. Redis 데이터 구조의 부적절한 사용
성능에 적합하지 않은 시나리오에서 Redis를 사용하면 문자열 유형 키를 사용하여 대용량 바이너리 파일 데이터를 저장하는 등 키 값이 너무 커집니다.
2. 정크 데이터를 제때 정리하지 못함
유효하지 않은 데이터를 정기적으로 정리하지 못하여 HASH형 키의 구성원 수가 계속 늘어나고 있습니다. 어떠한 삭제 메커니즘도 없이 계속해서 데이터를 받기만 하기 때문에 가치는 무한히 증가할 것입니다.
3. 부정확한 사업추정
사업 개시 전 기획 및 설계에 대한 고려가 부족하였고, Key 내 구성원이 합리적으로 분할되지 않아 개별 Key 내 구성원이 너무 많아졌습니다.
4. 유명인과 인터넷 유명인의 팬 목록, 특정 핫뉴스에 대한 댓글 목록
특정 유명인/인터넷 유명인의 팬을 저장하기 위해 List 데이터 구조를 사용한다고 가정해 보겠습니다. 팬 수가 많기 때문에 핫 뉴스에 대한 댓글 목록 핫 뉴스에는 클릭률과 댓글이 많기 때문에 목록 컬렉션에 많은 요소가 저장되므로 값이 너무 높아질 수 있습니다. 커서 Big Key 문제가 발생합니다.
1. 요청 차단
빅 키에 해당하는 값이 상대적으로 커서 읽고 쓸 때 시간이 오래 걸려 후속 요청 처리가 차단될 수 있습니다. Redis의 핵심 스레드는 단일 스레드이므로 모든 요청이 순차적으로 처리됩니다. 이전 요청이 완료되지 않으면 후속 요청이 처리되지 않습니다.
2. 메모리 증가
빅키를 읽는 데 소모되는 메모리가 일반 키보다 커질 경우 OOM(메모리 오버플로)이 발생하거나 최대 메모리 maxmemory 설정 값에 도달할 수 있습니다. of redis 쓰기 차단 또는 중요한 키가 제거됩니다.
3. 차단된 네트워크
큰 단일 값을 읽으면 서버 네트워크 카드의 더 많은 대역폭을 차지하고 속도가 느려지며 서버의 다른 Redis 인스턴스 또는 애플리케이션에 영향을 미칠 수 있습니다.
4. 마스터-슬레이브 동기화 및 마스터-슬레이브 전환에 미치는 영향
큰 키를 삭제하면 메인 라이브러리가 오랫동안 차단되어 동기화가 중단되거나 마스터-슬레이브 전환이 발생합니다.
1. redis와 함께 제공되는 명령 식별을 사용하세요
예를 들어 공식 Redis 클라이언트 redis-cli와 --bigkeys 매개변수를 사용하여 특정 인스턴스의 5가지 데이터 유형(문자열, 해시, list, set, zset)의 최대 키입니다.
서비스를 차단하지 않고 온라인으로 스캔할 수 있다는 장점이 있고, 정보가 적고 내용이 정확하지 않다는 단점이 있습니다.
2. 디버그 개체 키 명령
을 사용하여 들어오는 개체(키 이름)에 따라 키를 분석하고 대량의 데이터를 반환합니다. serializedlength의 값은 키의 직렬화된 길이입니다. 키의 직렬화된 길이는 메모리 공간의 실제 길이와 동일하지 않습니다. 또한 디버그 개체는 실행 비용이 많이 드는 디버깅 명령이며 실행 중일 때 다른 요청이 입력됩니다. Redis는 실행될 때까지 차단됩니다. 그리고 한 번에 하나의 키에 대한 정보만 확인할 수 있으므로 공식적으로 권장하지는 않습니다.
3. redis-rdb-tools 오픈 소스 도구
이 방법은 redis 인스턴스에서 bgsave를 실행하는 것입니다. bgsave는 redis의 스냅샷 백업을 트리거하고, rdb 지속성 파일을 생성한 다음, 덤프된 rdb 파일을 분석합니다. 큰 열쇠를 찾아보세요.
얻은 핵심 정보가 상세하고, 선택적 매개변수가 많으며, 맞춤형 요구 사항을 지원한다는 장점이 있으며, 결과 정보를 json 또는 csv 형식으로 선택할 수 있으며, 후속 처리가 오프라인이 필요하다는 단점이 있습니다. 작업을 수행하고 결과를 얻는 데 오랜 시간이 걸립니다.
Big Key 문제를 해결하려면 키에 해당하는 값의 크기를 줄이는 것, 즉 String 데이터 구조의 경우 List, Hash, Set에 대해 저장된 문자열의 길이를 줄이는 것뿐입니다. 및 ZSet 데이터 구조를 사용하여 집합의 요소 수를 줄입니다.
1. 큰 키를 분할하세요
큰 키를 키-값과 같은 여러 개의 작은 키로 분할하고 각 키의 수나 크기가 합리적인 범위 내에 있는지 확인한 다음 다른 키를 가져오거나 mget을 사용하여 일괄적으로 가져오는 방식으로 저장합니다.
2. 큰 키를 정리하세요
Redis에서 큰 키를 정리하고 Redis에서 해당 데이터를 삭제하세요. Redis는 4.0부터 UNLINK 명령을 제공했습니다. 이 명령은 들어오는 키를 비차단 방식으로 천천히 그리고 점진적으로 정리할 수 있으며 UNLINK를 통해 큰 키나 초대형 키도 안전하게 삭제할 수 있습니다.
3. Redis의 메모리, 네트워크 대역폭, 시간 초과 및 기타 지표를 모니터링합니다.
시스템을 모니터링하고 합리적인 Redis 메모리 경보 임계값을 설정하여 현재 Redis 메모리와 같은 큰 키가 생성될 수 있음을 알려줍니다. 사용량이 70%를 초과하고, Redis 메모리의 증가율이 1시간 이내에 20%를 초과하는 등.
4. 유효하지 않은 데이터를 정기적으로 정리합니다
특정 Key가 증분 방식으로 많은 양의 데이터를 기록했지만 데이터의 적시성을 무시한 경우 대량의 유효하지 않은 데이터가 축적됩니다. 잘못된 데이터는 예약된 작업을 통해 정리할 수 있습니다.
5. 값 압축
직렬화 및 압축 알고리즘을 사용하여 키 크기를 제어하지만 직렬화와 역직렬화 모두 특정 성능 소모를 유발한다는 점에 유의해야 합니다. 압축 후에도 값이 여전히 매우 큰 경우 키를 추가로 분할하는 것을 고려할 수 있습니다.
(1) [권장 사항]: 가독성 및 관리 용이성
회사 이름(또는 데이터베이스 이름)을 앞에 붙이고(키 충돌을 방지하기 위해) 회사 이름과 같이 콜론으로 구분합니다. 테이블 이름: id
o2o: order:1
(2) [제안]: Simplicity
의미를 보장하면서 키 길이를 제어하세요. 키가 많은 경우 메모리 사용량을 무시할 수 없습니다. 예:
user:{uid}:friends:messages:{mid}는 u:{uid}m:{mid}
(3)으로 단순화됩니다. [필수]: 특수 문자를 포함하지 마세요
카운터 예: 공백 포함 , 개행, 단일 문자 큰따옴표 및 기타 이스케이프 문자
위 내용은 Redis에서 Big Key 문제를 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
