Redis에 저장된 키 이름은 표준화되지 않았으며 상대적으로 임의적입니다.
Redis는 저장소로 사용되므로 데이터 손실의 위험이 있으며,
Redis는 만료 시간을 설정하지 않고 키를 캐시합니다. 저주파 데이터를 캐시하면 많은 메모리가 소모되어 서비스가 중단됩니다. 애플리케이션이 키를 얻을 때 많은 네트워크 대역폭을 차지하며 삭제하면 쉽게 정체가 발생할 수 있습니다.
Redis 클라이언트를 부적절하게 사용하면 클라이언트 비밀번호 때문에 시간이 초과될 수 있습니다. 연결 풀이 많이 사용되지 않습니다. 연결 재시도 횟수가 많아 시스템 포트 리소스가 고갈됩니다.
Redis 클라이언트 명령을 잘못 사용하면 쿼리 속도가 느려지고 다른 애플리케이션 서비스에 영향을 줍니다.
Redis 사용 비즈니스 시나리오 권장 사항 및 제안
제한된 시간 시나리오: Redis 만료 명령을 사용하여 세션 만료 및 갱신, 휴대폰 확인 코드 등을 설정합니다.
Redis의 목록 및 정렬된 세트 데이터 구조를 사용하여 다양한 복합 순위 애플리케이션
데이터 수집 작업: Redis 목록, 집합, 정렬 집합을 사용하여 교차점, 합집합, 차이 집합 등의 데이터 계산을 용이하게 합니다.
연속 체크인: 사용할 수 있습니다. redis 비트맵 데이터 구조는 로그인 관련 서비스를 구현합니다.
Counter: Redis incr 및 incrby 명령을 사용하여 API 호출 번호 통계, API 현재 제한 및 기타 시나리오를 구현합니다.
분산 잠금: setnx 기능을 사용합니다. 배포 잠금을 작성하는 Redis, Redisson과 같은 일반적인 오픈 소스 구성 요소
우아한 키를 설계하는 방법
그렇다면 어떻게 하면 더 우아한 열쇠를 디자인할 수 있을까요? 편집자의 실제 경험과 함정을 바탕으로 자세히 이야기해 보겠습니다.
1. 다음 모범 사례 규칙을 따르세요.
키 길이는 44바이트를 초과할 수 없습니다.
특수 문자를 포함하지 마세요.
위 제안과 관련하여 다음과 같은 장점이 있습니다.
읽기 가능 키 구조, order:user:10, 우리는 이것이 사용자 주문과 관련된 키라는 것을 한눈에 알 수 있습니다.
유지 관리에 편리합니다. 응용 프로그램이나 비즈니스에 따라 접두사가 매우 편리합니다. 시각적 클라이언트 도구 또는 명령줄에서 키 검색 및 위치를 위해
사용 중에 userId와 같은 값을 키로 사용하여 여러 사람이 발생하는 캐시 키 충돌을 피하세요.
문자열 유형을 키로 사용하세요. 기본 인코딩에는 int, embstr 및 raw가 포함되어 있어 메모리 사용량을 효과적으로 줄일 수 있습니다. embstr을 사용하면 지속적인 메모리 공간을 사용하기 때문에 더 적은 메모리를 차지하면서 44바이트보다 작은 문자열을 처리할 수 있습니다. 키를 입력하는 경우 요소 수는 1000개 미만인 것이 좋습니다.
2. 빅키는 피하세요
빅키는 일반적으로 키의 크기와 예:
Key 자체의 데이터 볼륨이 너무 큽니다. 문자열 유형 키의 값은 5MB입니다.
Key의 멤버 수가 너무 큽니다. : ZSET 유형 키, 구성원 수는 10,000입니다.
2. BigKey의 피해
네트워크 정체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 내부 및 외부의 네트워크 데이터를 모니터링합니다. 경고 값을 초과하면 사전에 경고합니다.
세 가지, 적절한 데이터 유형을 사용하세요
이 문제를 해결하려면 근본적으로 일반적으로 사용되는 데이터 유형에 대한 깊은 이해와 숙달이 필요합니다. 이를 기반으로 다양한 비즈니스 시나리오에 대한 솔루션을 설계할 수 있습니다. 사용자 개체 목록과 같은 데이터를 캐시하는 방법에 대해 생각해 보겠습니다.
옵션 1: 키는 usrId이고, 값은 객체의 직렬화된 문자열이며, 데이터 구조는 다음과 유사합니다.
장점: 작은 메모리 사용량, 효율적인 작업
단점: val을 얻은 후 완전한 개체를 얻으려면 추가 데이터베이스 검색이 필요합니다. 3: 해시 구조를 사용하여 객체를 캐시하며 데이터는 다음과 같습니다.Redis 캐시는 실제 사용 중입니다. 애플리케이션 내 사용 제안
[권장] 캐시를 워밍업하세요. 데이터에 액세스하기 전에 데이터 저장 계층에 직접 들어오는 많은 요청을 방지하기 위해 캐시를 예열해야 하며, 비즈니스 상황에 따라 적절한 핫 데이터와 콜드 데이터를 구분하고 핫 데이터를 예열해야 합니다. 라이센스 정보, apikey 등
[권장] 로컬 캐시를 함께 사용하세요. 분산 아키텍처에서는 로컬 캐싱이 데이터 액세스의 안정성과 속도를 향상시킬 수 있지만 상태 저장 서버 노드를 도입하지 않도록 주의해서 사용해야 합니다. 로컬 캐시가 애플리케이션 서버 리소스를 과도하게 점유하여 애플리케이션 노드 충돌을 일으키는 것을 방지하세요 [권장] 캐시 변경 전략, 데이터베이스를 먼저 업데이트한 다음 캐시를 업데이트하세요.[권장] 한 번의 비즈니스 호출에는 여러 번 방문해야 합니다. redis 서버, 파이프라인 또는 기타 일괄 작업 방법을 사용할 수 있습니다.
비즈니스 사양을 사용하세요
핫 데이터와 콜드 데이터의 분리를 고려해야 하며, 빈도가 높은 비즈니스 쿼리에는 Redis를 사용하고, 빈도가 낮은 쿼리에는 데이터베이스 사용을 고려해야 합니다. Redis에서는 데이터 손실 위험이 있으므로 데이터베이스에서 데이터를 구현해야 합니다. 손실된 데이터를 Redis에 자동으로 로드하고 캐시
list, set, hash와 같은 O(N) 명령을 주의해서 사용하세요. 구조, hgetall, lrange, smembers, zrange 등은 사용할 수 없습니다. 대신 hscan 및 sscan을 사용하여 우선순위를 지정하세요.
위 내용은 Redis 키-값 설계에 사용되는 방법은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!