Redis에서 캐시 단축키 문제를 처리하는 방법에 대해 이야기해 볼까요? 일반적으로 사용되는 솔루션 공유-Redis-php.cn

Redis의 단축키 문제를 어떻게 처리하나요? 다음 기사에서는 Redis 캐시 단축키 문제에 대한 일반적인 솔루션을 소개합니다. 도움이 되길 바랍니다.

Redis에서 캐시 단축키 문제를 처리하는 방법에 대해 이야기해 볼까요? 일반적으로 사용되는 솔루션 공유

일부 C 측 비즈니스를 수행할 때 데이터베이스의 부담을 대체하고 비즈니스 응답 시간을 줄이기 위해 1차 캐시를 도입하는 것은 불가피합니다. 실제로 문제를 해결하기 위해 매번 미들웨어가 도입됩니다. , 이는 이전 기사 "실제 데이터베이스 및 캐시 일관성"에서 언급한 캐시 일관성을 달성하는 방법과 같은 많은 새로운 문제를 필연적으로 야기할 것입니다. 실제로 Redis를 1차 캐시로 사용할 때 발생할 수 있는 핫키, 큰 키 등과 같은 다른 문제도 있을 것입니다. 이번 글에서는핫키 및 단축키문제를 해결하는 방법. -


       배경
       热key（hot key）问题来讨论，如何合理的解决
       热key问题。
       
       背景
       热key是什么问题，如何导致的？
       一般来说，我们使用的缓存Redis都是多节点的集群版，对某个key进行读写时，会根据该key的hash计算出对应的slot，根据这个slot就能找到与之对应的分片(一个master和多个slave组成的一组redis集群)来存取该K-V。但是在实际应用过程中，对于某些特定业务或者一些特定的时段（比如电商业务的商品秒杀活动），可能会发生大量的请求访问同一个key。所有的请求（且这类请求读写比例非常高）都会落到同一个redis server上，该redis的负载就会严重加剧，此时整个系统增加新redis实例也没有任何用处，因为根据hash算法，同一个key的请求还是会落到同一台新机器上，该机器依然会成为系统瓶颈2，甚至造成整个集群宕掉，若此热点key的value 也比较大，也会造成网卡达到瓶颈，这种问题称为 “热key” 问题。【相关推荐：Redis视频教程】
       如下图1、2所示，分别是正常redis cluster集群和使用一层proxy代理的redis 集群key访问。
       
       
       如上所说，热key会给集群中的少部分节点带来超高的负载压力，如果不正确处理，那么这些节点宕机都有可能，从而会影响整个缓存集群的运作，因此我们必须及时发现热key、解决热key问题。
       1.热key探测
       热key探测，看到由于redis集群的分散性以及热点key带来的一些显著影响，我们可以通过由粗及细的思考流程来做热点key探测的方案。
       1.1 集群中每个slot的qps监控
       热key最明显的影响是整个redis集群中的qps并没有那么大的前提下，流量分布在集群中slot不均的问题，那么我们可以最先想到的就是对于每个slot中的流量做监控，上报之后做每个slot的流量对比，就能在热key出现时发现影响到的具体slot。虽然这个监控最为方便，但是粒度过于粗了，仅适用于前期集群监控方案，并不适用于精准探测到热key的场景。
       1.2 proxy的代理机制作为整个流量入口统计
       如果我们使用的是图2的redis集群proxy代理模式，由于所有的请求都会先到proxy再到具体的slot节点，那么这个热点key的探测统计就可以放在proxy中做，在proxy中基于时间滑动窗口，对每个key做计数，然后统计出超出对应阈值的key。为了防止过多冗余的统计，还可以设定一些规则，仅统计对应前缀和类型的key。这种方式需要至少有proxy的代理机制，对于redis架构有要求。
       1.3 redis基于LFU的热点key发现机制
       redis 4.0以上的版本支持了每个节点上的基于LFU的热点key发现机制，使用redis-cli –hotkeys即可，执行redis-cli时加上–hotkeys选项。可以定时在节点中使用该命令来发现对应热点key。
       
       如下所示，可以看到redis-cli –hotkeys단축키어떻게 발생하나요?일반적으로 우리가 사용하는 캐시 Redis는 다중 노드 클러스터 버전입니다. 특정 키를 읽고 쓸 때 해당 키의 해시를 기반으로 해당 슬롯을 계산하고 이를 기반으로 해당 슬롯을 찾을 수 있습니다. 슬롯. 샤딩(하나의 마스터와 여러 개의 슬레이브로 구성된 Redis 클러스터 집합)은 K-V에 액세스하는 데 사용됩니다. 그러나 실제 신청 과정에서 일부 특정 비즈니스 또는 특정 기간(예: 전자상거래 비즈니스의 제품 플래시 세일 활동)에서는 동일한 키에 대한 액세스 요청이 많이 발생할 수 있습니다. 모든 요청(그리고 그러한 요청의 읽기/쓰기 비율은 매우 높음)은 동일한 Redis 서버에 속하게 되며, 이때 Redis의 로드는 심각하게 증가하게 됩니다. 전체 시스템에 새로운 Redis 인스턴스를 추가하게 됩니다. 해시 알고리즘에 따르면 동일한 키에 대한 요청은 여전히 동일한 새 시스템에 속하므로 시스템 병목 현상이 발생하고2 이 핫스팟 키의 값이 상대적으로 높을 경우 전체 클러스터가 충돌할 수도 있습니다. 크면 네트워크 카드에 병목 현상이 발생하게 됩니다. 이 문제를 "핫 키" 문제라고 합니다. [관련 권장 사항:
       Redis 동영상 튜토리얼] 그림 1과 2에 표시됨 아래는 각각 프록시 프록시 계층을 사용하는 일반적인 Redis 클러스터 클러스터 및 Redis 클러스터 키 액세스입니다.
       위에서 언급했듯이, 핫키는 클러스터의 소수 노드에 매우 높은 로드 압력을 가져옵니다. 올바르게 처리하지 않으면 이러한 노드가 다운되어 전체 캐시 클러스터의 작동에 영향을 미칠 수 있으므로 제때에 핫키를 검색해야 합니다. 핫키 문제를 해결하세요.
       1. 단축키 감지단축키 감지, redis 클러스터와 단축키의 분산으로 인해 몇 가지 중요한 영향이 있음을 확인하고 대략적인 방법을 사용할 수 있습니다. 핫스팟 키 감지 솔루션을 개발하는 과정에 대해 알아보세요.
       1.1 클러스터 내 각 슬롯의 QPS 모니터링단축키의 가장 확실한 영향은 전체 Redis 클러스터의 QPS가 클러스터 내 슬롯들 사이에 트래픽이 고르게 분포되어 있다는 전제 하에, 먼저 각 슬롯의 트래픽을 모니터링하고, 각 슬롯의 트래픽을 비교한 후, 영향을 받은 특정 슬롯을 발견하면 단축키가 나타납니다. 이 모니터링은 가장 편리하지만 세분화가 너무 거칠기 때문에 초기 클러스터 모니터링 솔루션에만 적합하며 단축키가 정확하게 감지되는 시나리오에는 적합하지 않습니다.
       1.2 프록시 메커니즘은 전체 트래픽 입구 통계로 사용됩니다.그림 2에서 redis 클러스터 프록시 모드를 사용하는 경우, 모든 요청은 먼저 프록시로 이동한 다음 특정 슬롯 노드로 이동합니다. 그런 다음 이 단축키의 감지 통계는
       시간 슬라이딩 창을 기반으로 프록시에서 수행될 수 있습니다. 각 키를 계산한 다음 해당 임계값을 초과하는 키를 계산합니다. 너무 많은 중복 통계를 방지하기 위해 접두사 및 유형에 해당하는 키만 계산하도록 일부 규칙을 설정할 수도 있습니다. 이 방법에는 최소한 프록시 메커니즘이 필요하며 Redis 아키텍처에 대한 요구 사항이 있습니다.
       1.3 redis LFU 기반 핫스팟 키 검색 메커니즘Redis 4.0 이상의 버전은 각 노드에서 LFU 기반 핫스팟을 지원합니다. 메커니즘을 사용하려면
       redis-cli –hotkeys를 사용하세요. redis-cli를 실행할 때 –hotkeys 옵션을 추가하세요. 노드에서 정기적으로 이 명령을 사용하여 해당 핫스팟 키를 검색할 수 있습니다.
       as 그림과 같이
       redis-cli –hotkeys의 실행 결과와 단축키에 대한 통계 정보를 확인할 수 있으며, 이 명령의 실행 시간이 길며 예약 실행을 설정할 수 있습니다. 통계를 수집합니다.
       1.4 Redis 클라이언트 기반 탐지
       Redis 명령은 매번 클라이언트에서 발행되므로 이를 기반으로 Redis 클라이언트의 일부 코드에서 통계 계산을 수행할 수 있으며 각 클라이언트는 시간 슬라이딩 창을 기반으로 통계를 수행합니다. 특정 임계값을 초과하면 서버에 보고되고, 서버는 이를 각 클라이언트에 균일하게 전송하고 해당 만료 시간을 구성합니다.
       이 방법은 더 아름다워 보이지만 실제로는 클라이언트 측 수정으로 인해 실행 중인 프로세스에 더 큰 메모리 오버헤드가 발생하기 때문에 일부 애플리케이션 시나리오에서는 그다지 적합하지 않습니다. 더 직접적으로는 다음과 같은 자동 메모리 관리 기능이 있는 언어입니다. Java와 goLang은 객체를 더 자주 생성하여 gc를 트리거하고 인터페이스 응답 시간을 증가시키는 것은 예측하기 쉽지 않습니다.优美，其实在一些应用场景中并不是那么合适，因为在client端这一侧的改造，会给运行的进程带来更大的内存开销，更直接的来说，对于Java和goLang这种自动内存管理的语言，会更加频繁的创建对象，从而触发gc导致接口响应耗时增加的问题，这个反而是不太容易预料到的事情。
       最终可以通过各个公司的基建，做出对应的选择。
       2.热key解决
       通过上述几种方式我们探测到了对应热key或者热slot，那么我们就要解决对应的热key问题。解决热key也有好几种思路可以参考，我们一个一个捋一下。
       2.1 对特定key或slot做限流
       一种最简单粗暴的方式，对于特定的slot或者热key做限流，这个方案明显对于业务来说是有损的，所以建议只用在出现线上问题，需要止损的时候进行特定的限流。
       2.2 使用二级（本地）缓存
       本地缓存也是一个最常用的解决方案，既然我们的一级缓存扛不住这么大的压力，就再加一个二级缓存吧。由于每个请求都是由service发出的，这个二级缓存加在service端是再合适不过了，因此可以在服务端每次获取到对应热key时，使用本地缓存存储一份，等本地缓存过期后再重新请求，降低redis集群压力。以java为例，guavaCache就是现成的工具。以下示例：
       
        //本地缓存初始化以及构造 private static LoadingCache> configCache = CacheBuilder.newBuilder() .concurrencyLevel(8) //并发读写的级别，建议设置cpu核数 .expireAfterWrite(10, TimeUnit.SECONDS) //写入数据后多久过期 .initialCapacity(10) //初始化cache的容器大小 .maximumSize(10)//cache的容器最大 .recordStats() // build方法中可以指定CacheLoader，在缓存不存在时通过CacheLoader的实现自动加载缓存 .build(new CacheLoader>() { @Override public List