Linux 운영 및 유지 관리를 위해 알아야 할 Redis 경험

Redis는 현재 기술 커뮤니티에서 매우 인기가 있습니다. Redis는 Antirez의 소규모 개인 프로젝트에서 인메모리 데이터 스토리지의 업계 표준이 되기까지 먼 길을 걸어왔습니다. 결과적인 모범 사례 세트를 통해 대부분의 사람들은 Redis를 올바르게 사용할 수 있습니다.

아래에서는 Redis를 올바르게 사용한 10가지 경험을 살펴보겠습니다.

1. KEYS 사용 중지 *

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

for key in'keys *': 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、Hashes 是你的最佳选择

以一种优雅的方式引入 hashes 吧。hashes 将会带给你一种前所未有的体验。之前我曾看到过许多类似于下面这样的key结构：

foo:first_name foo:last_name foo:address

上面的例子中，foo 可能是一个用户的用户名，其中的每一项都是一个单独的 key。这就增加了 犯错的空间，和一些不必要的 key。使用 hash 代替吧，你会惊奇地发现竟然只需要一个 key ：

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、设置 key 值的存活时间

无论什么时候，只要有可能就利用key超时的优势。一个很好的例子就是储存一些诸如临时认证key之类的东西。当你去查找一个授权key时——以OAUTH为例——通常会得到一个超时时间。这样在设置key的时候，设成同样的超时时间，Redis就会自动为你清除！而不再需要使用KEYS *来遍历所有的key了，怎么样很方便吧？

6. 적절한 재활용 전략을 선택하세요

이제 키 지우기 주제에 대해 이야기했으므로 재활용 전략에 대해 이야기해 보겠습니다. Redis 인스턴스 공간이 가득 차면 일부 키 회수를 시도합니다. 사용량에 따라 키에 시간 초과를 설정한 경우 휘발성-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시간 기술 지원을 제공하므로 고려해 볼 수 있습니다.