10가지 Redis 사용 팁
- 尚앞으로
- 2020-06-16 16:45:302395검색
Redis는 현재 기술 커뮤니티에서 매우 인기가 있습니다. Redis는 Antirez의 소규모 개인 프로젝트에서 인 메모리 데이터 스토리지의 업계 표준이 되기까지 먼 길을 걸어왔습니다. 결과적인 모범 사례 세트를 통해 대부분의 사람들은 Redis를 올바르게 사용할 수 있습니다.
1. KEYS 사용 중지 *
좋습니다. 이 명령에 도전하여 이 글을 시작하는 것은 좋은 방법이 아닐 수도 있지만 가장 중요한 포인트일 수 있습니다. 우리는 redis 인스턴스의 통계를 살펴볼 때 핵심 정보가 명확하게 표시되도록 "KEYS *" 명령을 빠르게 입력할 때가 많습니다.
프로그래밍 관점에서 우리는 다음과 같은 의사 코드를 작성하는 경향이 있습니다.
for key in'keys *': doAllTheThings()
그러나 1300만 개의 키가 있으면 실행 속도가 느려집니다. 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의 아버지인 Salvatore는 Redis-Benchmark 결과를 참고로 사용합니다. "GET/SET 명령을 실행하여 Redis를 테스트하는 것은 자동차의 거울을 청소할 때 Ferrari의 앞유리 와이퍼의 효과를 테스트하는 것과 같습니다. 비오는 날." 많은 사람들이 저를 찾아와 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 인스턴스 공간이 가득 차면 일부 키 회수를 시도합니다. 사용량에 따라 키에 시간 초과를 설정한 경우 휘발성-lru 전략을 사용하는 것이 좋습니다.
그러나 캐시와 유사한 것을 실행 중이고 키에 대한 시간 초과 메커니즘을 설정하지 않은 경우 allkeys-lru 재활용 메커니즘 사용을 고려할 수 있습니다.
7. 데이터가 중요하다면 Try/Except를 사용하세요
중요한 데이터를 Redis 인스턴스에 넣을 수 있는지 확인해야 한다면 try/except 블록에 넣는 것이 좋습니다. 거의 모든 Redis 클라이언트는 "보내고 잊어버리기" 전략을 채택하므로 키가 실제로 Redis 데이터베이스에 있는지 여부를 고려해야 하는 경우가 많습니다.
Redis 명령에 try/expect를 넣는 것의 복잡성에 대해서는 이 문서에서 다루지 않습니다. 그렇게 하면 중요한 데이터가 있어야 할 위치에 배치될 수 있다는 점만 알면 됩니다.
8. 인스턴스를 소진하지 마세요
가능하면 여러 Redis 인스턴스의 작업 부하를 분산하세요. 버전 3.0.0부터 Redis는 클러스터를 지원합니다. Redis 클러스터를 사용하면 키 범위를 기반으로 마스터/슬레이브 모드를 포함하는 일부 키를 분리할 수 있습니다. 클러스터링 뒤에 숨은 완전한 "마법"은 여기에서 찾을 수 있습니다.
하지만 튜토리얼을 찾고 있다면 이곳이 완벽한 장소입니다. 클러스터링이 옵션이 아닌 경우 네임스페이스를 고려하고 키를 여러 인스턴스에 분산시키는 것을 고려하세요.
9. 코어는 많을수록 좋나요? !
물론 틀렸어요. Redis는 단일 스레드 프로세스이며 지속성이 활성화된 경우에도 최대 2개의 코어만 소비합니다. 단일 호스트에서 여러 인스턴스를 실행할 계획이 아니라면 개발 및 테스트 환경에서만 가능하기를 바랍니다. ——그렇지 않으면 Redis 인스턴스에 2개 이상의 코어가 필요하지 않습니다.
10. 고가용성
지금까지 Redis Sentinel은 철저한 테스트를 거쳤으며 많은 사용자가 이를 프로덕션 환경(ObjectRocket 포함)에 적용했습니다. 애플리케이션이 Redis에 크게 의존하는 경우 오프라인 상태가 되지 않도록 고가용성 솔루션을 마련해야 합니다.
자세한 내용은 java 기본 튜토리얼칼럼
을 참고해주세요.위 내용은 10가지 Redis 사용 팁의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!