Redis-Cache 동시 캐시 눈사태 캐시 침투 인터뷰

이 기사에서는 주로 캐시 동시성, 캐시 눈사태 및 캐시 침투의 문제와 솔루션을 설명합니다.

캐시 동시성

캐시 동시성이란?

시나리오 : 매일 Douyin을 사용하고 WeChat 짧은 동영상을 시청할 때 댓글 목록이 표시됩니다. 댓글 목록에서 댓글을 쿼리 할 때 먼저 Redis 캐시를 쿼리합니다.있는 경우 즉시 반환하고 그렇지 않은 경우에는 go 데이터베이스는 데이터를 쿼리 한 다음 캐시를 업데이트하고 데이터를 반환합니다. 이때 방문이 많은 경우 동시에 댓글을 조회하는 C 측이 여러 개 있고, Redis 캐시는 데이터를 캐시하지 않는 경우가 발생합니다. 이때 여러 C 측이 동시에 데이터베이스를 조회합니다. 시각. 위의 현상을 캐시 동시성이라고합니다.

캐시 적중

미스 캐시

그렇긴하지만 동시성 캐싱으로 인해 어떤 피해가 발생하는지

데이터베이스가 높은 동시성을 견딜 수없고 트래픽이 클 경우 직접 파괴 될 수 있기 때문에 데이터베이스에 대한 부담이 급격히 증가했습니다. 사용자에게 매우 불리합니다. 오늘날 인터넷에서 앱 애플리케이션의 교체율은 매우 높습니다. 높음, 약간의 부주의로 사용자는 다른 앱에 의해 빼앗겨 기업에 재앙입니다. Redis가 문제인지, 문제가 없는지 알 수 있습니다. 문제가 있으면 큰 문제 일 것입니다. 그 이유를 아는 것을 강조 할 필요가있는 것입니다.

이제 우리는 캐싱 동시성의 심각도를 이미 알고 있으므로 해결 방법

문제를 해결하기 전에 문제가 발생한 이유를 분석해야합니다. 그냥 얘기하자면 인터뷰 나 직장에서 문제가 생기거나 즉시 바꾸거나 바이두가 제시 한 방법에 따라 시도해보세요. 이 문제 해결 방법은 올바르지 않습니다. 일반적인 문제 해결 방법은 다음과 같습니다. 오류 발생-문제 찾기-문제 분석-솔루션 설계-문제 해결. 캐시 동시성 문제로 돌아가서 "캐시 동시성이 발생하는 이유"를 분석해 보겠습니다.

캐시 동시성이 필요한 이유

이유 1 : 동시성이 높은 시나리오에서 시스템이 방금 시작되었고 캐시가 워밍업되지 않았고 캐시가 비어 있으며 분산 잠금이 사용되지 않았습니다.
이유 2 : 높은 동시성 시나리오에서 머신이 일정 시간 동안 실행되었지만 캐시가 실패하고 분산 잠금이 쓸모가 없습니다.
이유 3 : 높은 동시성 시나리오에서 Redis가 다운 됨

위의 세 가지 이유는 캐시 동시성을 유발합니다. 다른 이유가 생략 된 경우 메시지 영역에 추가 할 수 있습니다.

이유를 알고 나면 그 이유에 대한 해결책을 설계 할 수 있습니다.

해결책

이유 1과 2의 해결책은 분산 잠금입니다. 이를 통해 한 스레드는 데이터베이스에 요청하고 다른 스레드는 중단 할 수 있습니다. 스레드는 데이터베이스를 확인한 후 캐시를 업데이트하고 다른 스레드는 캐시에 액세스하여 데이터를 반환합니다. 분산 잠금을 사용하는 방법과 기본 구현에 대해서는 실제로주의해야 할 세부 사항이 더 있지만 여기서는 설명 할 필요가 없습니다. 관련 기사는 후속으로 게시 될 것입니다. 외로움, 당신은 Google에 갈 수 있습니다.
세 번째 이유는 프로그램 : Redis 고 가용성입니다. 고가용 성과 관련하여 마스터-슬레이브 구조 + 센티넬 모드 또는 Redis 클러스터에 지나지 않습니다. (링크 추가)

분산 잠금 및 Redis의 고 가용성은 실제로 예방 조치이며 사전 작업이어야합니다. 캐시 동시성이 실제로 발생했다면이 모듈 서비스의 트래픽 항목을 줄여서이 모듈 서비스의 과도한 트래픽으로 인해 MySQL을 직접 죽이지 않도록하여 다른 모듈 서비스에 영향을 미치게됩니다. . Redis가 다운되면 먼저 트래픽 입구를 줄인 다음 기계를 빠르게 다시 시작하십시오.

물론 Hystrix에 대한 전류 제한, 다운 그레이드 및 서비스 거부 작업을 미리 수행하는 것이 가장 좋습니다. 현재 제한 및 다운 그레이드, 전류 제한은 이름에서 알 수 있듯이 흐름을 제한하는 것이며, 예를 들어 초당 최대 1000 개까지 통과 할 수있는 트래픽의 양을 제한하는 것입니다. 1000을 초과하는 요청은 일부 기본값을 반환하거나 친숙한 알림 : 시스템이 현재 사용 중입니다. 나중에 다시 시도하는 것과 같이 다운 그레이드됩니다. 서비스 거부는 마지막 방어선입니다. 일정 시간 후에도 트래픽이 여전히 크면 서비스를 직접 거부합니다. 서비스 거부는 Redis가 트래픽에 의해 유출되지 않도록 보호하기위한 것입니다. 복구가 더 중요합니다. 시간이 많이 걸리고 트래픽이 많았 기 때문에 방금 다시 시작했기 때문에 트래픽 물결이 Redis를 직접 제거하여 Double Kill을 완료했습니다. 서비스 거부, 트래픽이 적 으면 더 빨리 정상 서비스 상태로 돌아갑니다. 서비스 거부는 최후의 수단입니다.

kohlrabi가 인터넷 산업에 처음 진출했을 때 저는 그것에 대해 아무것도 몰랐습니다. Redis를 사용하기 전에는 Redis가 매우 강력하고 캐싱에 적합하다는 것을 알았을뿐입니다. Redis에 대한 참고 사항,에서 키 * 명령을 사용할 수 없다는 점을 제외하면 생산 환경, 그 밖의 모든 것은 이해하지 못합니다. 당시 리뷰 프로젝트에서는 트래픽이 매우 크고 동시성이 높기 때문에 쿼리 댓글 인터페이스에 캐시 동시성 문제가 있었는데 다행히 기본값 응답과 전류 제한 + 다운 그레이드 조치가 미리 이루어졌다. 다음은 분산 잠금을 사용하여 캐시 동시성을 해결하기위한 키 코드입니다.

  @Autowired
  private DistributionLock locker;
  
 //没缓存，查数据库，获取评论
  if (comment == null) {
      //加分布式锁，只允许一个线程去回源
      if(locker.trylock(Constants.QUERYCOMMENT+moduleType+resourceId)){
          try {
              comment = getDataFromRedis(moduleType, resourceId);
              if(comment == null){
                  //缓存没数据，去数据库查
                  comment = getDataFromMongoDB(moduleType, resourceId);
              }
          }finally {
              locker.unlock(Constants.QUERYCOMMENT+moduleType+resourceId);
          }
      }

분산 잠금

다음으로 캐시 침투에 대해 계속 이야기하십시오.

캐시 침투

캐시 침투 란?

시나리오 : 주석을 쿼리 할 때 id = -1 인 데이터를 직접 쿼리하면 캐시가 누락 된 다음이를 찾기 위해 데이터베이스로 이동하지만 누락됩니다. 위의 상황을 캐시 침투라고합니다. 이해하기 쉬운 단어로 요약하면 데이터베이스에 없어야하는 데이터를 찾는 것을 캐시 침투라고합니다.

캐시 침투의 단점은 무엇입니까?

트래픽이 큰 경우 서비스가 직접 사용되어 서비스를 사용할 수 없게됩니다.

방법론을 계속 따르십시오.

캐시 침투가 발생하는 이유

첫 번째 이유는 해커 공격과 같은 비정상적인 요청이 요청을 위해 특수한 형식의 데이터를 특별히 구성하여 시스템에 큰 부담을주기 때문입니다.
두 번째 이유는 사용자가 정상적인 요청에서 잘못된 데이터를 입력했기 때문입니다.

해결책

해결 방법 1 : 빈 개체 캐시 : 요청시 먼저 캐시에 액세스하고 데이터를 찾을 수없는 다음 쿼리 할 데이터베이스로 이동하면 데이터베이스가 해당 데이터를 찾을 수 없으며 클라이언트에 null을 반환합니다. 캐시 (키, "null")를 비동기 적으로 업데이트하고 짧은 만료 시간을 추가합니다.
솔루션 2 : 솔루션 1에는 실제로 명백한 단점이 있습니다. 즉, 요청 된 데이터가 존재하지 않아야하는 경우이 시점에서 캐시는 많은 쓸모없는 (key1, "null"), (key2, "null")을 캐시합니다. . 메모리 낭비. 이때 데이터 체크섬과 블룸 필터를 결합 할 수 있습니다.

데이터 검증과 관련하여이 문제는 특히 중요합니다. 특히 돈과 직접 관련된 일부 서비스에서는 데이터 검증이 매우 중요합니다. 데이터 검증 없이는 대기업의 상사가 Bentley를 잃게됩니다. 소규모 회사는 직접 파산 할 수 있습니다. 다음은 Rutabaga 학생의 회사 사례입니다.
사례 1
사례 2

어쨌든 좋은 개발 습관을 기르는 것은 평생 유익 할 수 있습니다.

캐시 눈사태

캐시 눈사태 란?

시나리오 : 주석 목록에서 일련의 주석이 핫 주석이되지만 안타깝게도이 주석 배치는 현재 Redis 캐시에서 유효하지 않습니다. 캐시가 누락되고 많은 수의 요청이 추가되기 때문에 모든 댓글은 데이터베이스로 이동하여 댓글을 쿼리합니다., 따라서 데이터베이스에 큰 부담을 주거나 충돌이 발생합니다. 이 상황을 캐시 눈사태라고합니다.

캐시 눈사태의 단점

그것은 데이터베이스에 큰 압력을 가하고 심지어 데이터베이스를 손상시켜 시스템이 정상적으로 서비스를 제공하지 못하게합니다.

캐시 눈사태가 발생하는 이유

이유 1 : Redis가 다운되었습니다. 이는 동시에 여러 키가 실패하는 것과 같습니다.
두 번째 이유는 redis가 다운되지 않았고 여러 키가 정상적으로 도착하면 실패하기 때문입니다.

요약 : 인터뷰 중에이 질문이 발생하면 redis가 다운되었는지 여부와 같이 별도로 답변하는 것이 가장 좋습니다. 면접관에게 명확한 인상을줍니다.

해결책

해결 방법 1, 시스템이 다운 되었기 때문에 원인 1을 해결 한 다음 고 가용성, redis 클러스터, 감시 모드, 장애 조치 및 장애 복구를 생각하고 모니터링 및 경보도해야합니다. 장애 조치를 자동으로 완료 할 수없는 경우 수동 개입입니다.
솔루션 2, 만료 시간 = 만료 시간 + 임의 시간, 원인 2를 해결합니다.
옵션 3, 만료되지 않음 만료 시간으로 인해 눈사태가 발생 했으므로 만료없이 수행 할 수 있습니다. 어떤 사람들은 캐시 일관성을 보장하는 방법을 물을 수 있습니다. 활성 백그라운드 업데이트 : mysql을 통해 업데이트 할 때 mq가 Binlog를 수신하고 다시 호출하여 캐시를 업데이트하도록합니다. 캐시와 데이터베이스 데이터를 일관되게 유지하십시오.
솔루션 4는 애플리케이션 아키텍처의 관점에서 볼 때 전류 제한, 성능 저하 및 융합을 통해 영향을 줄일 수있을뿐만 아니라 이러한 재해를 방지하기 위해 다중 레벨 캐싱을 피할 수 있습니다. 사용중인 마이크로 서비스 아키텍처가 SpringCloud 인 경우 Hystrix를 직접 사용하여 전류 제한, 다운 그레이드, 퓨징을 달성하고 구성 파일을 수정할 수 있습니다.

보충

캐시 분석은 하나의 키만 만료되는 캐시 눈사태입니다.

요약하자면

기사 전반에 걸쳐 거의 모든 내용이 오류보고-포지셔닝 문제-분석 문제-설계 솔루션-문제 해결 방법론에 따라 작성되었습니다. 이 기사에서는 캐시 동시성, 캐시 침투 및 캐시 눈사태의 정의, 위험, 원인 및 솔루션을 소개합니다. Rutabaga는이 기사를 읽은 후에 지식을 배우는 것뿐만 아니라 문제의 위치를 파악하는 방법론 (문제 분석, 문제 해결)도 습득하기를 바랍니다. 지식 포인트, 이들은 미래에 잊혀 질 수 있지만 방법을 습득하면 트릭을 볼 수 있습니다.

봐 주셔서 감사합니다 글이 잘 쓰여졌다 고 생각하시는 분은 관심을 가지고 공유 해주세요. (저에게 매우 유용합니다)
기사의 개선이 필요하다고 생각 되시면 제게 제안을 기다리겠습니다. 메시지를 남겨주세요.
뭔가보고 싶으면 메시지를 기다리겠습니다.
귀하의 지원과 지원은 저의 창작에 가장 큰 동기입니다!