Redis 키-값 설계에 사용되는 방법은 무엇입니까?

Redis 사용의 불규칙성

• Redis에 저장된 키 이름은 표준화되지 않았으며 상대적으로 임의적입니다.

• Redis는 저장소로 사용되므로 데이터 손실의 위험이 있으며,

• Redis는 만료 시간을 설정하지 않고 키를 캐시합니다. 저주파 데이터를 캐시하면 많은 메모리가 소모되어 서비스가 중단됩니다. 애플리케이션이 키를 얻을 때 많은 네트워크 대역폭을 차지하며 삭제하면 쉽게 정체가 발생할 수 있습니다.

• Redis 클라이언트를 부적절하게 사용하면 클라이언트 비밀번호 때문에 시간이 초과될 수 있습니다. 연결 풀이 많이 사용되지 않습니다. 연결 재시도 횟수가 많아 시스템 포트 리소스가 고갈됩니다.

• Redis 클라이언트 명령을 잘못 사용하면 쿼리 속도가 느려지고 다른 애플리케이션 서비스에 영향을 줍니다.

• Redis 사용 비즈니스 시나리오 권장 사항 및 제안

높은 동시성 시나리오: 핫스팟 데이터 캐싱, 시스템의 전반적인 응답 속도를 향상시키고 데이터베이스의 IO 압력

• 제한된 시간 시나리오: Redis 만료 명령을 사용하여 세션 만료 및 갱신, 휴대폰 확인 코드 등을 설정합니다.

• Redis의 목록 및 정렬된 세트 데이터 구조를 사용하여 다양한 복합 순위 애플리케이션

• 데이터 수집 작업: Redis 목록, 집합, 정렬 집합을 사용하여 교차점, 합집합, 차이 집합 등의 데이터 계산을 용이하게 합니다.

• 연속 체크인: 사용할 수 있습니다. redis 비트맵 데이터 구조는 로그인 관련 서비스를 구현합니다.

• Counter: Redis incr 및 incrby 명령을 사용하여 API 호출 번호 통계, API 현재 제한 및 기타 시나리오를 구현합니다.

• 분산 잠금: setnx 기능을 사용합니다. 배포 잠금을 작성하는 Redis, Redisson과 같은 일반적인 오픈 소스 구성 요소

• 우아한 키를 설계하는 방법

Redis의 온라인 성능 최적화에 있어서 불합리한 키 설계는 종종 문제의 근본 원인이라고 할 수 있습니다. 문제는 본질적으로 제가 개인적으로 본 바로는 대부분의 학생들이 Redis를 사용할 때 키 설계에 대한 개념이 거의 없다는 것입니다. 왜냐하면 대부분의 학생들이 사용하는 시나리오는 key/val이고 해당 데이터 구조는 string key/string val이기 때문입니다.

redis에 대한 이해가 깊은 학생들은 보관할 때 키 디자인이 최대한 짧아야 한다는 것을 알 수 있으며, 중간에 계층 구조를 갖는 것이 가장 좋습니다. Segmentation...을 진행하는 것이 가장 좋습니다.

그렇다면 어떻게 하면 더 우아한 열쇠를 디자인할 수 있을까요? 편집자의 실제 경험과 함정을 바탕으로 자세히 이야기해 보겠습니다.

1. 다음 모범 사례 규칙을 따르세요.

기본 형식을 따르세요: [업체 이름]:[데이터 이름]:

1. 키 길이는 44바이트를 초과할 수 없습니다.

2. 특수 문자를 포함하지 마세요.

3. 위 제안과 관련하여 다음과 같은 장점이 있습니다.

읽기 가능 키 구조, order:user:10, 우리는 이것이 사용자 주문과 관련된 키라는 것을 한눈에 알 수 있습니다.

• 유지 관리에 편리합니다. 응용 프로그램이나 비즈니스에 따라 접두사가 매우 편리합니다. 시각적 클라이언트 도구 또는 명령줄에서 키 검색 및 위치를 위해

• 사용 중에 userId와 같은 값을 키로 사용하여 여러 사람이 발생하는 캐시 키 충돌을 피하세요.

• 문자열 유형을 키로 사용하세요. 기본 인코딩에는 int, embstr 및 raw가 포함되어 있어 메모리 사용량을 효과적으로 줄일 수 있습니다. embstr을 사용하면 지속적인 메모리 공간을 사용하기 때문에 더 적은 메모리를 차지하면서 44바이트보다 작은 문자열을 처리할 수 있습니다. 키를 입력하는 경우 요소 수는 1000개 미만인 것이 좋습니다.

• 2. 빅키는 피하세요

1. 빅키는 무엇인가요?

빅키는 일반적으로 키의 크기와 예:

• Key 자체의 데이터 볼륨이 너무 큽니다. 문자열 유형 키의 값은 5MB입니다.

• Key의 멤버 수가 너무 큽니다. : ZSET 유형 키, 구성원 수는 10,000입니다.

키에 있는 구성원의 데이터 양이 너무 큽니다. 해시 유형 키에는 구성원이 1,000개만 있지만 이 구성원의 총 값은 100MB입니다.

2. BigKey의 피해

네트워크 정체

BigKey에서 읽기 요청을 실행할 때 소량의 QPS로 인해 대역폭 사용량이 가득 차서 Redis 인스턴스는 물론 물리적 시스템까지 작동하지 않을 수 있습니다.
• 데이터 왜곡

BigKey가 위치한 Redis 인스턴스의 메모리 사용량은 다른 인스턴스보다 훨씬 높으며 데이터 샤드의 메모리 리소스 균형을 맞출 수 없습니다.

Redis 차단

• 요소가 많은 해시, 리스트, zset 등에 대한 작업은 시간이 오래 걸리고 메인 스레드가 차단될 수 있습니다.

CPU 압력

• BigKey의 데이터 직렬화 및 역직렬화 CPU 사용량이 급증하여 시스템의 Redis 인스턴스 및 기타 애플리케이션에 영향을 미칩니다.

3. BigKey를 검색하는 방법

설치된 시스템에서 redis-cli --bigkeys 명령을 실행하세요. 활용 redis-cli에서 제공하는 --bigkeys 매개변수는 모든 키를 순회 및 분석하고, 키의 전체 통계 정보와 각 데이터의 상위 1개 빅 키를 반환할 수 있습니다. 프로그램을 작성하고 scan을 사용하면 Redis의 모든 키를 스캔하고 strlen, hlen 및 기타 명령을 사용하여 키 길이를 결정합니다(여기서는 메모리 사용량을 권장하지 않음).

• 타사 도구 사용

Redis-Rdb-Tools와 같은 타사 도구를 사용하여 RDB 스냅샷 파일을 분석하고 메모리 사용량을 종합적으로 분석합니다.

• 네트워크 모니터링을 사용합니다.

사용자 지정 도구를 사용하여 Redis 내부 및 외부의 네트워크 데이터를 모니터링합니다. 경고 값을 초과하면 사전에 경고합니다.

• 세 가지, 적절한 데이터 유형을 사용하세요

위에서 언급했듯이 Redis를 처음 사용하는 많은 학생들은 많은 비즈니스 시나리오에서 간단한 키/발값 구조를 사용합니다. 이것이 합리적인지, 아니면 이런 것인지 깊이 생각하지 마세요. 향후 관련 성능 문제를 일으킬까요?

이 문제를 해결하려면 근본적으로 일반적으로 사용되는 데이터 유형에 대한 깊은 이해와 숙달이 필요합니다. 이를 기반으로 다양한 비즈니스 시나리오에 대한 솔루션을 설계할 수 있습니다. 사용자 개체 목록과 같은 데이터를 캐시하는 방법에 대해 생각해 보겠습니다.

• 옵션 1: 키는 usrId이고, 값은 객체의 직렬화된 문자열이며, 데이터 구조는 다음과 유사합니다.

장점: 쉬운 액세스, 간단하고 대략적, json만 수행하면 됩니다. 액세스할 때 객체로 변환하세요.

단점: 데이터 결합이 충분하지 않습니다. 객체가 필드를 추가하거나 삭제하면 캐시 재구성 비용이 매우 높습니다.

• 옵션 2: 목록 구조를 사용합니다. 캐시 사용자 ID 목록, 데이터 구조는 다음과 같습니다.

장점: 작은 메모리 사용량, 효율적인 작업

단점: val을 얻은 후 완전한 개체를 얻으려면 추가 데이터베이스 검색이 필요합니다. 3: 해시 구조를 사용하여 객체를 캐시하며 데이터는 다음과 같습니다.

장점: 하단 레이어는 공간을 거의 차지하지 않고 객체의 모든 필드에 유연하게 액세스할 수 있는 ziplist를 사용합니다.

• Redis 캐시는 실제 사용 중입니다. 애플리케이션 내 사용 제안

[권장] 캐시를 워밍업하세요. 데이터에 액세스하기 전에 데이터 저장 계층에 직접 들어오는 많은 요청을 방지하기 위해 캐시를 예열해야 하며, 비즈니스 상황에 따라 적절한 핫 데이터와 콜드 데이터를 구분하고 핫 데이터를 예열해야 합니다. 라이센스 정보, apikey 등

[권장] 로컬 캐시를 함께 사용하세요. 분산 아키텍처에서는 로컬 캐싱이 데이터 액세스의 안정성과 속도를 향상시킬 수 있지만 상태 저장 서버 노드를 도입하지 않도록 주의해서 사용해야 합니다. 로컬 캐시가 애플리케이션 서버 리소스를 과도하게 점유하여 애플리케이션 노드 충돌을 일으키는 것을 방지하세요

[권장] 캐시 변경 전략, 데이터베이스를 먼저 업데이트한 다음 캐시를 업데이트하세요.

[권장] 한 번의 비즈니스 호출에는 여러 번 방문해야 합니다. redis 서버, 파이프라인 또는 기타 일괄 작업 방법을 사용할 수 있습니다.

[권장] 대규모 목록, 세트, ​​해시, 엄청난 양의 저장 공간. 많은 수의 요소를 가져오는 경우 큰 지연이 발생하여 다른 명령의 실행이 차단됩니다. 여러 개의 작은 리스트, 세트, ​​해시 테이블로 분할하는 것이 좋습니다

• 비즈니스 사양을 사용하세요

개발에 사용되는 Redis든 다른 미들웨어든 개발 및 사용에 있어서는 세트로 개발하는 것이 가장 좋습니다. 이 사양은 대부분의 개발자가 인식하고 실제로 테스트해야 하며 일부 문제를 효과적으로 피할 수 있습니다. 일단 사양으로 지정되면 다음 사항을 지침으로 삼아야 합니다.
Redis는 캐시 데이터로 배치되어야 하며 대규모 데이터를 저장하는 데 사용할 수 없습니다(데이터베이스를 대체할 수 없음).
Redis는 다음과 같이 읽기가 많고 쓰기가 적은 시나리오에 적합합니다.
키의 생존 시간이 불확실한 경우에는 만료 시간을 설정하여 키의 수명 주기를 제어하는 ​​것이 가장 좋습니다.

• 핫 데이터와 콜드 데이터의 분리를 고려해야 하며, 빈도가 높은 비즈니스 쿼리에는 Redis를 사용하고, 빈도가 낮은 쿼리에는 데이터베이스 사용을 고려해야 합니다. Redis에서는 데이터 손실 위험이 있으므로 데이터베이스에서 데이터를 구현해야 합니다. 손실된 데이터를 Redis에 자동으로 로드하고 캐시

• list, set, hash와 같은 O(N) 명령을 주의해서 사용하세요. 구조, hgetall, lrange, smembers, zrange 등은 사용할 수 없습니다. 대신 hscan 및 sscan을 사용하여 우선순위를 지정하세요.

위 내용은 Redis 키-값 설계에 사용되는 방법은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!