Redis에서 핫스팟 키는 어떻게 생성됩니까? 어떻게 해결하나요?

다음 글에서는 Redis의 핫스팟 키를 이해하고, 핫스팟 키가 생성되는 이유, 핫스팟 키를 찾는 방법, 핫스팟 키에 대한 솔루션을 소개합니다. 모두에게 도움이 되기를 바랍니다.

핫키 생성 이유

1. 생성되는 데이터보다 사용자가 소비하는 데이터가 훨씬 많습니다

핫키 문제는 접속 요청이 많다는 것입니다. 특정 순간에 Redis에 고정된 키가 존재하여 캐시 중단 및 DB에 대한 요청이 발생하여 캐시 서비스 및 DB 서비스에 과부하가 걸리고 이로 인해 애플리케이션 서비스의 가용성에 영향을 미칩니다. [관련 추천: Redis 영상 튜토리얼]

가장 흔한 것은 XX 연예인 결혼/부정 등 웨이보에서 핫한 검색어입니다. 그러면 XX별에 대한 키가 순간적으로 늘어나 핫데이터 문제가 발생하게 됩니다. Weibo도 때때로 충돌합니다.

마찬가지로, 널리 게시되고 시청되는 핫뉴스, 핫댓글, 연예인 라이브 방송 등은 많이 읽고 적게 쓰는 전형적인 시나리오도 뜨거운 이슈를 야기할 것입니다.

2. 요청 조각화가 집중되어 단일 서버의 성능 제한을 초과합니다.

서버가 액세스를 위해 데이터를 읽을 때 데이터가 分片분할 처리됩니다. 특정 호스트 서버에 해당 키에 접근하면 서버 제한을 ​​초과하는 경우 핫키 문제가 발생합니다.

핫키 문제의 위험성

1. 트래픽이 집중되어 물리적 네트워크 카드의 상한선에 도달합니다.

특정 호스트에서 특정 핫스팟 키에 대한 요청이 해당 호스트의 네트워크 카드 상한선을 초과하는 경우 과도한 트래픽 집중으로 인해 서버의 다른 서비스가 진행되지 않게 됩니다.

2. 요청이 너무 많아 캐시 샤딩 서비스가 중단되었습니다.

핫스팟이 너무 집중되어 있고 핫스팟 키의 캐시가 너무 커서 현재 캐시 용량을 초과하는 경우 캐시 샤딩 서비스가 압도됩니다.

3. DB 고장으로 인한 업무 폭주.

이때 캐시 서비스가 다운되어 또 다른 요청이 발생하면, DB 자체의 성능이 취약하여 대용량 요청 시 요청 침투가 발생하기 쉽습니다. 이는 눈사태 현상으로 이어질 수 있으며 장비 성능에 심각한 영향을 미칩니다.

단축키 발견

1. 비즈니스 경험을 토대로 어떤 키가 핫키인지 추정해 보세요

실제로 이 방법은 꽤 실현 가능합니다. 예를 들어, 어떤 제품이 반짝 세일 중이라면, 이 제품의 키는 단축키로 판단될 수 있습니다. 단점은 분명합니다. 모든 기업에서 어떤 키가 단축키인지 추정할 수 있는 것은 아닙니다.

2. 클라이언트 측에서 수집

Redis를 실행하기 전에 데이터 통계를 위한 코드 한 줄을 추가하는 방법입니다. 데이터를 수집하는 방법에는 여러 가지가 있으며, 외부 통신 시스템에 알림 메시지를 보내는 것도 가능합니다. 단점은 클라이언트 코드에 침입이 발생한다는 것입니다.

3. 프록시 레이어에서 수집

일부 클러스터 아키텍처는 다음과 같습니다. 프록시는 Twemproxy일 수 있습니다. 는 통합출입구입니다. 수집 및 보고는 프록시 계층에서 수행될 수 있지만 모든 Redis 클러스터 아키텍처에 프록시가 있는 것은 아닙니다. Twemproxy，是统一的入口。可以在Proxy层做收集上报，但是缺点很明显，并非所有的redis集群架构都有proxy。

4、用redis自带命令

• monitor命令：该命令可以实时抓取出redis服务器接收到的命令，然后写代码统计出热key是啥。当然，也有现成的分析工具可以给你使用，比如redis-faina。但是该命令在高并发的条件下，有内存增暴增的隐患，还会降低redis的性能。
• hotkeys参数：redis 4.0.3提供了redis-cli的热点key发现功能，执行redis-cli时加上–hotkeys选项即可。但是该参数在执行的时候，如果key比较多，执行起来比较慢。

5、自己抓包评估

Redis客户端使用TCP协议与服务端进行交互，通信协议采用的是RESP。自己写程序监听端口，按照RESP协议规则解析数据，进行分析。缺点就是开发成本高，维护困难，有丢包可能性。

以上五种方案，各有优缺点。根据自己业务场景进行抉择即可。

热点Key的解决方案

1、利用二级缓存

比如利用ehcache、spring cache，甚至是一个HashMap都可以。在你发现热key以后，把热key加载到系统的JVM中。

针对这种热key请求，会直接从jvm中取，而不会走到redis层。

假设此时有十万个针对同一个key的请求过来,如果没有本地缓存，这十万个请求就直接怼到同一台redis上了。
现在假设，你的应用层有50台机器，OK，你也有jvm缓存了。这十万个请求平均分散开来，每个机器有2000个请求，会从JVM中取到value值，然后返回数据。避免了十万个请求怼到同一台redis上的情形。

2、读写分离

读写分离就是将同为 Write 的请求发送到 Master 模块内，而将 Read 的请求发送至 ReadOnly

4. redis에 내장된 명령 사용

• 모니터 명령 Strong>: 이 명령은 Redis 서버가 수신한 명령을 실시간으로 캡처한 다음 단축키를 계산하는 코드를 작성할 수 있습니다. 물론 redis-faina와 같이 사용할 수 있는 기성 분석 도구도 있습니다. 그러나 동시성이 높은 조건에서 이 명령은 메모리가 갑자기 증가할 수 있는 숨겨진 위험이 있으며 Redis 성능도 저하시킵니다.
• hotkeys 매개변수: redis 4.0.3에서는 redis-cli 실행 시 –hotkeys 옵션을 추가합니다. 할 수 있다. 그러나 이 매개변수가 실행될 때 키가 많으면 실행 속도가 느려집니다.

5. 자체 패킷 캡처 및 평가

Redis 클라이언트는 TCP 프로토콜과 서버를 사용합니다. 상호작용을 위해 통신 프로토콜은 RESP를 사용합니다. 포트를 수신하고 RESP 프로토콜 규칙에 따라 데이터를 구문 분석하고 분석을 수행하는 프로그램을 직접 작성하세요. 단점은 높은 개발 비용, 어려운 유지 관리, 패킷 손실 가능성 등입니다.

위의 다섯 가지 옵션에는 각각 장점과 단점이 있습니다. 비즈니스 시나리오에 따라 결정을 내리세요.

핫스팟 키 솔루션

활용도 2단계 캐시🎜🎜예를 들어 ehcache, spring 캐시 또는 HashMap을 사용하세요. 단축키를 발견한 후 시스템의 JVM에 단축키를 로드하십시오. 🎜🎜이러한 단축키 요청의 경우 redis 레이어로 이동하지 않고 jvm에서 직접 가져옵니다. 🎜🎜현재 동일한 키에 대해 100,000개의 요청이 있다고 가정합니다. 로컬 캐시가 없으면 이 100,000개의 요청이 동일한 Redis로 직접 전송됩니다.
이제 애플리케이션 계층에 50개의 머신이 있다고 가정합니다. JVM 캐시도 있습니다. 이 100,000개의 요청은 균등하게 분산되며 각 시스템에는 2,000개의 요청이 있습니다. 값은 JVM에서 가져온 다음 데이터가 반환됩니다. 이렇게 하면 수십만 개의 요청이 동일한 Redis로 전송되는 상황을 피할 수 있습니다. 🎜🎜2. 읽기 및 쓰기 분리🎜🎜읽기 및 쓰기 분리는 쓰기는 <code>Master 모듈로 전송되고, Read 요청은 ReadOnly 모듈로 전송됩니다. 🎜🎜모듈의 읽기 전용 노드를 추가로 확장할 수 있으며 이 키를 여러 Redis에 저장할 수 있습니다. 핫키 요청이 들어오면 백업이 있는 Redis 서버를 무작위로 선택하여 값에 접근하고 데이터를 반환합니다. 이는 핫 리딩(hot reading) 문제를 효과적으로 해결합니다. 🎜🎜읽기와 쓰기의 분리는 읽기 핫스팟 기능의 유연한 확장, 대량의 핫스팟 키 저장 기능, 클라이언트 친화성이라는 장점도 있습니다. 🎜🎜더 많은 프로그래밍 관련 지식을 보려면 🎜프로그래밍 비디오🎜를 방문하세요! ! 🎜

위 내용은 Redis에서 핫스팟 키는 어떻게 생성됩니까? 어떻게 해결하나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!