Redis는 현재 기술 커뮤니티에서 뜨겁습니다. Antirez의 소규모 개인 프로젝트에서 메모리 데이터 스토리지에 대한 업계 표준이 되기까지 먼 길을 왔습니다. 이에 따라 대부분의 사람들이 Redis를 올바르게 사용하는 데 동의할 수 있는 일련의 모범 사례가 제공됩니다. 아래에서 Redis를 올바르게 사용하기 위한 10가지 간단한 팁을 살펴보겠습니다.
1. 키 사용 중지 *
좋아요, 그래서 당신에게 소리치는 것은 이 기사를 시작하기에 좋은 방법이 아닐 수도 있습니다. 하지만 가장 중요한 포인트라고 할 수 있습니다. 너무 자주 나는 redis 인스턴스를 보고, 빠른 명령 통계를 실행하고, 나를 똑바로 응시하는 눈부신 KEYS를 봅니다. 공정하게 말해서 프로그래밍 방식의 관점에서 볼 때 다음과 같은 작업을 수행하는 의사 코드를 갖는 것이 합리적일 것입니다.
for key in 'keys *':
doAllTheThings()그러나 예를 들어 1,300만 개의 키가 있으면 상황이 느려질 것입니다. KEYS는 O(n)이고 여기서 n은 반환된 키의 수이므로 복잡성은 dbsize에 의해 제한됩니다. 또한 이 전체 작업 중에는 인스턴스에 대해 다른 어떤 것도 실행할 수 없습니다.
대안으로 SCAN을 확인하여 다음을 수행할 수 있습니다. 대신 증분으로 데이터베이스를 스캔합니다. 이것은 인터레이터에서 작동하므로 원하는 대로 멈추고 이동할 수 있습니다.
2. Redis 속도를 늦추는 요인 알아보기
Redis에는 가장 장황한 로그가 없기 때문에 인스턴스 내부에서 정확히 무슨 일이 일어나고 있는지 추적하기 어려운 경우가 많습니다. 다행히 Redis는 다음을 표시하는 commandstat 유틸리티를 제공합니다.
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. TTL을 설정하세요!
가능하면 만료되는 키를 활용하십시오. 완벽한 예는 임시 인증 키와 같은 것을 저장하는 것입니다. OAUTH를 예로 들어 인증 키를 검색할 때 종종 만료 시간이 제공됩니다. 키를 설정할 때 동일한 만료로 설정하면 Redis가 자동으로 정리합니다! 더 이상 KEYS *가 모든 키를 반복할 필요가 없습니까?
6. 적절한 퇴거 정책 선택
키 정리에 대한 주제에 대해 이야기하는 동안 축출에 대해 알아보겠습니다. Redis 인스턴스가 가득 차면 Redis가 키 축출을 시도합니다. 사용 사례에 따라 만료되는 키가 있다고 가정할 때 volatile-lru를 적극 권장합니다. 캐시와 같은 것을 실행하고 만료 세트가 없는 경우 allkeys-lru를 고려할 수 있습니다. 여기에서 사용 가능한 옵션을 확인하는 것이 좋습니다.
7. 데이터가 중요한 경우 시도/제외
데이터가 Redis 인스턴스에 전달되는 것이 절대적으로 중요하다면 try/except를 사용하는 것이 좋습니다. 거의 모든 Redis 클라이언트는 "실행 후 잊어버리도록" 구성되어 있으므로 키가 실제로 데이터베이스에 도달하지 않는 경우를 항상 고려해야 합니다. 이 경우 redis 호출에 추가되는 복잡성은 거의 없으며 중요한 데이터가 있어야 할 위치에 있는지 확인할 수 있습니다.
8. 하나의 인스턴스를 범람하지 마십시오
가능하면 여러 Redis 인스턴스 간에 워크로드를 분할합니다. 버전 3.0.0부터 Redis 클러스터를 사용할 수 있습니다. Redis 클러스터를 사용하면 키 범위를 기반으로 주어진 마스터/슬레이브 세트 간에 키를 분리할 수 있습니다. Cluster 이면의 마법에 대한 전체 분석은 여기에서 찾을 수 있습니다. 튜토리얼을 찾고 있다면 더 이상 찾지 마십시오. 클러스터링이 옵션이 아닌 경우 네임스페이스를 고려하고 여러 인스턴스에 키를 배포하십시오. 데이터 파티셔닝에 대한 놀라운 기록은 여기 redis.io 웹사이트에서 찾을 수 있습니다.
9. 더 많은 코어 =더 나은 것, 맞죠?!
잘못된. Redis는 단일 스레드 프로세스이며 지속성을 활성화한 경우 최대 2개의 코어를 사용합니다. 동일한 호스트에서 여러 인스턴스를 실행할 계획이 아니라면(이 경우 개발 테스트를 위해서만 가능합니다!) Redis 인스턴스에 2개 이상의 코어가 필요하지 않습니다.
10. 하 모든 것!
Redis Sentinel은 이제 매우 잘 테스트되었으며 많은 사용자가 프로덕션에서 실행하고 있습니다(ObjectRocket 포함!). 애플리케이션에 Redis에 크게 의존하고 있다면 온라인 상태를 유지하기 위해 HA(고가용성) 솔루션을 고려해야 합니다. 물론 이 모든 것을 직접 관리하고 싶지 않다면 ObjectRocket이 24시간 연중무휴로 소비를 지원하는 HA 플랫폼을 제공합니다. 한 번 시도해 보세요.