집 > 기사 > 백엔드 개발 > Redis를 올바르게 사용하기 위한 10가지 팁

Redis를 올바르게 사용하기 위한 10가지 팁

小云云원래의: 2017-12-14 13:59:382371검색

Redis는 현재 기술 커뮤니티에서 매우 인기가 있습니다. Antirez의 소규모 개인 프로젝트부터 메모리 내 데이터 저장을 위한 업계 표준이 되기까지 Redis는 많은 발전을 이루었습니다. 아래에서는 Redis를 올바르게 사용하기 위한 10가지 팁을 살펴보겠습니다.

1. KEYS 사용 중지 *

좋습니다. 이 명령에 도전하여 이 글을 시작하는 것은 좋은 방법이 아닐 수도 있지만 실제로 가장 중요한 포인트일 수 있습니다. 우리는 redis 인스턴스의 통계를 살펴볼 때 핵심 정보가 명확하게 표시되도록 "KEYS *" 명령을 빠르게 입력할 때가 많습니다. 공평하게 말하면 프로그래밍 관점에서 우리는 다음과 같은 의사 코드를 작성하는 경향이 있습니다.

for key in &#39;keys *&#39;: 
 doAllTheThings()

하지만 키가 1,300만 개이면 실행 속도가 느려집니다. KEYS 명령의 시간 복잡도는 O(n)(여기서 n은 반환할 키 수)이므로 이 명령의 복잡도는 데이터베이스 크기에 따라 달라집니다. 그리고 이 작업을 실행하는 동안에는 인스턴스에서 다른 명령을 실행할 수 없습니다.

대체 명령으로 SCAN을 살펴보세요. 보다 사용자 친화적인 방식으로 수행할 수 있습니다. SCAN은 증분 반복으로 데이터베이스를 스캔합니다. 이 작업은 커서의 반복자를 기반으로 수행되므로 언제든지 원하는 대로 중지하거나 계속할 수 있습니다.

2. Redis 속도를 저하시키는 원인을 찾아보세요

Redis에는 자세한 로그가 없기 때문에 Redis 인스턴스 내부에서 어떤 작업이 수행되는지 파악하기가 매우 어렵습니다. 다행히 Redis는 다음과 같은 명령 통계 도구를 제공합니다.

127.0.0.1:6379> INFO commandstats 
# Commandstats 
cmdstat_get:calls=78,usec=608,usec_per_call=7.79 
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20 
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00 
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10

이 도구를 통해 명령이 실행된 횟수, 실행되는 데 걸린 시간(밀리초) 등 모든 명령 통계의 스냅샷을 볼 수 있습니다. 명령을 실행합니다(각 명령의 총 시간과 평균 시간)

CONFIG RESETSTAT 명령을 실행하여 재설정하면 완전히 새로운 통계 결과를 얻을 수 있습니다.

3. 일반화하는 대신 Redis-Benchmark 결과를 참조하십시오.

Redis의 아버지인 Salvatore는 다음과 같이 말했습니다. "GET/SET 명령을 실행하여 Redis를 테스트하는 것은 자동차 앞유리 와이퍼의 효율성을 테스트하는 것과 같습니다. 비 오는 날 거울." . 많은 사람들이 저를 찾아와 Redis-Benchmark 통계가 최적 결과보다 낮은 이유를 알고 싶어합니다. 하지만 다음과 같은 다양한 실제 상황을 고려해야 합니다. 어떤 클라이언트 운영 환경 제한이

적용될 수 있습니까?
버전 번호가 같은가요?
테스트 환경의 성능이 애플리케이션이 실행될 환경과 일치합니까?

Redis-Benchmark의 테스트 결과는 Redis-Server가 비정상적인 상태에서 실행되지 않도록 하는 벤치마크 포인트를 제공하지만, 이를 실제 "스트레스 테스트"로 받아들여서는 안 됩니다. 스트레스 테스트는 애플리케이션이 실행되는 방식을 반영해야 하며 프로덕션과 최대한 유사한 환경이 필요합니다.

4. 해시가 최선의 선택입니다

우아한 방식으로 해시를 소개하세요. 해시는 당신에게 전례 없는 경험을 선사할 것입니다. 이전에 다음과 유사한 키 구조를 많이 보았습니다.

foo:first_name 
foo:last_name 
foo:address

위의 예에서 foo는 사용자의 사용자 이름일 수 있으며 그 안의 각 항목은 별도의 키입니다. 이렇게 하면 오류와 불필요한 키의 여지가 늘어납니다. 대신 해시를 사용하면 키가 하나만 필요하다는 사실에 놀랄 것입니다.

127.0.0.1:6379> HSET foo first_name "Joe" 
(integer) 1 
127.0.0.1:6379> HSET foo last_name "Engel" 
(integer) 1 
127.0.0.1:6379> HSET foo address "1 Fanatical Pl" 
(integer) 1 
127.0.0.1:6379> HGETALL foo 
1) "first_name" 
2) "Joe" 
3) "last_name" 
4) "Engel" 
5) "address" 
6) "1 Fanatical Pl" 
127.0.0.1:6379> HGET foo first_name 
"Joe"

5. 키 값의 생존 시간을 설정하세요

가능하면 키 시간 초과를 활용하세요. 좋은 예는 임시 인증 키와 같은 것을 저장하는 것입니다. 인증 키를 조회할 때(예: OAUTH) 일반적으로 시간 초과가 발생합니다. 이런 방식으로 키를 설정할 때 동일한 제한 시간으로 설정하면 Redis가 자동으로 키를 지웁니다! 더 이상 모든 키를 탐색하기 위해 KEYS *를 사용할 필요가 없습니다. 얼마나 편리합니까?

6. 적절한 재활용 전략 선택

이제 키 지우기 주제에 대해 이야기했으므로 재활용 전략에 대해 이야기해 보겠습니다. Redis 인스턴스 공간이 가득 차면 일부 키 회수를 시도합니다. 사용량에 따라 키에 시간 제한을 설정한 경우 Volatile-lru 전략을 사용하는 것이 좋습니다. 그러나 캐시와 유사한 것을 실행 중이고 키에 대한 시간 초과 메커니즘을 설정하지 않은 경우 allkeys-lru 재활용 메커니즘 사용을 고려할 수 있습니다. 내 제안은 먼저 여기서 가능한 것이 무엇인지 확인하는 것입니다.

7. 데이터가 중요한 경우 Try/Except를 사용하세요

중요한 데이터를 Redis 인스턴스에 넣을 수 있는지 확인해야 한다면 try/except 블록에 넣는 것이 좋습니다. 거의 모든 Redis 클라이언트는 "보내고 잊어버리기" 전략을 채택하므로 키가 실제로 Redis 데이터베이스에 있는지 여부를 고려해야 하는 경우가 많습니다. Redis 명령에 try/expect를 넣는 것의 복잡성은 이 문서의 내용이 아닙니다. 그렇게 하면 중요한 데이터가 있어야 할 곳에 배치된다는 점만 알면 됩니다.

8. 인스턴스를 소진하지 마세요

가능하면 여러 Redis 인스턴스의 작업 부하를 분산하세요. 버전 3.0.0부터 Redis는 클러스터를 지원합니다. Redis 클러스터를 사용하면 키 범위에 따라 마스터/슬레이브 모드를 포함하는 일부 키를 분리할 수 있습니다. 클러스터링 뒤에 숨은 완전한 "마법"은 여기에서 찾을 수 있습니다. 하지만 튜토리얼을 찾고 있다면 이곳이 완벽한 장소입니다. 클러스터링이 옵션이 아닌 경우 네임스페이스를 고려하고 여러 인스턴스에 키를 분산시키는 것이 좋습니다. 데이터 배포 방법에 관해 redis.io 웹사이트에 훌륭한 리뷰가 있습니다.

9. 코어는 많을수록 좋나요?

물론 틀렸어요. Redis는 단일 스레드 프로세스이며 지속성이 활성화된 경우에도 최대 2개의 코어만 소비합니다. 단일 호스트에서 여러 인스턴스를 실행할 계획이 아니라면 개발 및 테스트 환경에서만 가능하기를 바랍니다. ——그렇지 않으면 Redis 인스턴스에 2개 이상의 코어가 필요하지 않습니다.

10. 고가용성

지금까지 Redis Sentinel은 철저한 테스트를 거쳤으며 많은 사용자가 이를 프로덕션 환경(ObjectRocket 포함)에 적용했습니다. 애플리케이션이 Redis에 크게 의존하는 경우 오프라인 상태가 되지 않도록 고가용성 솔루션을 마련해야 합니다. 물론 이러한 사항을 직접 관리하고 싶지 않다면 ObjectRocket은 고가용성 플랫폼과 7×24시간 기술 지원을 제공합니다. 관심이 있다면 고려해 볼 수 있습니다.

Redis를 올바르게 사용하기 위한 10가지 팁

관련 기사