저는 6개의 주요 제조업체를 인터뷰하여 잘 알려지지 않은 일반적인 Redis 인터뷰 질문(답변 및 분석 포함)을 요약하여 공유했습니다. 도움이 필요한 친구들이 모두 참고할 수 있기를 바랍니다.

Redis에 대한 일반적인 인터뷰 질문 요약(답변 분석 포함)

【관련 권장사항: Redis 동영상 튜토리얼】

지식 포인트 캐싱

어떤 유형의 캐시가 있나요?

캐싱은 높은 동시성 시나리오에서 핫스팟 데이터 액세스 성능을 향상시키는 효과적인 수단이며 프로젝트 개발 시 자주 사용됩니다.

캐시 유형은 로컬 캐시, 분산 캐시 및 다단계 캐시로 구분됩니다.

로컬 캐시:

로컬 캐시는 LRUMap로 구현할 수 있는 JVM 힙과 같은 프로세스의 메모리에 캐시되거나 Ehcache와 같은 도구를 사용할 수 있습니다. 달성하기 위해.

로컬 캐시는 메모리 액세스이며 원격 상호작용 오버헤드가 없으며 성능이 가장 좋습니다. 그러나 일반적으로 캐시는 용량이 작아 확장할 수 없습니다.

분산 캐시:

분산 캐시는 이 문제를 매우 잘 해결할 수 있습니다.

분산 캐시는 일반적으로 수평 확장성이 좋으며 대용량 데이터가 포함된 시나리오를 쉽게 처리할 수 있습니다. 단점은 원격 요청이 필요하고 성능이 로컬 캐싱만큼 좋지 않다는 것입니다.

다단계 캐시:

이런 상황의 균형을 맞추기 위해 다단계 캐시는 일반적으로 실제 비즈니스에서 사용됩니다. 로컬 캐시는 액세스 빈도가 가장 높은 일부 핫스팟 데이터와 기타 핫스팟만 저장합니다. 데이터는 분산 캐시 중간에 배치됩니다.

현재 1차 제조업체에서 이는 가장 일반적으로 사용되는 캐싱 솔루션이기도 합니다. 단일 캐싱 솔루션은 많은 동시성 시나리오를 지원하기 어려운 경우가 많습니다.

제거 전략

로컬 캐시이든 분산 캐시이든 더 높은 성능을 보장하기 위해 비용 및 메모리 제한으로 인해 저장된 데이터가 캐시 용량을 초과하는 경우 메모리를 사용하여 데이터를 저장합니다. , 캐시된 데이터가 제거되어야 합니다.

일반적인 제거 전략에는 가장 오래된 데이터를 제거하는 FIFO, 최근에 가장 적게 사용된 데이터를 제거하는 LRU, 최근에 가장 적게 사용된 데이터를 제거하는 LFU가 포함됩니다.

noeviction: 메모리 제한에 도달하고 클라이언트가 더 많은 메모리를 사용하게 하는 명령을 실행하려고 하면 오류를 반환합니다(대부분의 쓰기 명령이지만 DEL 및 몇 가지 예외)
allkeys- lru: 새로 추가된 데이터를 위한 공간을 확보하기 위해 가장 적게 사용된 키(LRU)를 재활용해 보세요.
휘발성-lru: LRU(최소 사용 키)를 재활용하려고 시도하지만 만료된 세트의 키만 사용하여 새로 추가된 데이터를 위한 공간을 확보합니다.
allkeys-random: 무작위 키를 재활용하여 새로 추가된 데이터를 위한 공간을 만듭니다.
휘발성-random: 새로 추가된 데이터를 위한 공간을 만들기 위해 무작위 키를 재활용합니다. 단, 만료된 세트의 키에 대해서만 가능합니다.
휘발성-ttl: 만료된 세트의 키를 재활용하고, 새로 추가된 데이터를 저장할 공간이 있도록 생존 시간(TTL)이 더 짧은 키에 우선순위를 부여합니다.

재활용 전제 조건을 충족하는 열쇠가 없으면 휘발성-lru, 휘발성-랜덤 및 휘발성-ttl 전략은 noeviction과 거의 동일합니다.

실제로 Lru 알고리즘은 익숙한 LinkedHashMap에서도 구현됩니다. 구현은 다음과 같습니다.

용량이 100을 초과하면 LRU 전략 실행을 시작합니다. 최근 사용되지 않은 TimeoutInfoHolder 개체 evict가 삭제되었습니다.

실제 인터뷰에서는 LUR 알고리즘을 작성하라는 메시지가 표시됩니다. 트릭이 너무 많아서 완료할 수 없습니다. Java 버전을 구현하기 위한 데이터 구조를 찾는 것은 원리를 알고 있는 한 비교적 쉽습니다.

Memcache

Memcache는 나중에 MC로 약칭되니 참고하세요.

먼저 MC의 특징을 살펴보겠습니다.

MC는 요청을 처리할 때 멀티 스레드 비동기 IO를 사용하므로 멀티 코어 CPU를 합리적으로 활용할 수 있으며 성능이 뛰어납니다.
MC는 간단한 기능을 갖고 있으며 메모리를 사용하여 데이터를 저장합니다. MC의 메모리 구조 및 석회화 문제에 대해 공식 웹사이트에서 확인할 수 있습니다.
MC는 캐시된 데이터에 대한 만료 날짜를 설정할 수 있으며 만료된 데이터는 삭제됩니다.
무효화 전략은 지연을 채택합니다. 무효화, 즉 데이터가 다시 사용될 때 유효하지 않은지 확인하는 것을 의미합니다.
용량이 가득 차면 만료된 키를 정리하는 것 외에도 데이터도 삭제됩니다. LRU 정책.
또한 MC 사용에는 몇 가지 제한 사항이 있는데, 이는 현재 인터넷 시나리오에서 매우 치명적이며 모두가

Redis

및 MongoDB를 선택하는 중요한 이유가 됩니다.

키는 250바이트를 초과할 수 없습니다. 값은 1M 바이트를 초과할 수 없습니다.

키의 최대 만료 시간은 30일입니다.
K-V 구조만 지원하며 지속성 및 마스터-슬레이브 동기화 기능을 제공하지 않습니다.
Redis

MC와의 쉬운 비교를 위해 Redis의 특징에 대해 간략하게 이야기해보겠습니다.

MC와 달리 Redis는 단일 스레드 모드를 사용하여 요청을 처리합니다. 여기에는 두 가지 이유가 있습니다. 하나는 비차단 비동기 이벤트 처리 메커니즘을 사용하기 때문이고, 다른 하나는 캐시된 데이터가 모두 메모리 작업이고 IO 시간이 너무 길지 않으며 단일 스레드가 비용을 피할 수 있다는 것입니다. 스레드 컨텍스트 전환.

는 지속성을 지원하므로 Redis는 캐시뿐만 아니라 NoSQL 데이터베이스로도 사용할 수 있습니다.
MC와 비교했을 때 Redis도 매우 큰 장점이 있습니다. 즉, K-V 외에도 목록, 집합, 정렬 집합, 해시 등과 같은 다양한 데이터 형식도 지원합니다.
Redis는 고가용성 서비스를 제공할 수 있는 마스터-슬레이브 동기화 메커니즘과
클러스터 배포 기능을 제공합니다.

Redis에 대한 자세한 설명

Redis의 지식 포인트 구조는 아래 그림과 같습니다.

Redis이 어떤 기능을 제공하는지 살펴보겠습니다!

먼저 기본 유형을 살펴보겠습니다.

String:

String 유형은

Redis

에서 가장 일반적으로 사용되는 유형이며, 내부 구현은 SDS(Simple Dynamic String)을 통해 저장됩니다. . SDS는 Java의 ArrayList와 유사하며, 중복 공간을 미리 할당하여 잦은 메모리 할당을 줄일 수 있습니다. 이것은 가장 간단한 유형으로, 간단한 KV 캐싱을 수행하는 일반적인 설정 및 가져오기입니다. 그러나 실제 개발 환경에서는 많은 사람들이 저장 및 사용을 위해 많은 복잡한 구조를

String

로 변환할 수 있습니다. 예를 들어 어떤 사람들은 저장을 위해 객체나

List

를 JSONString로 변환하고 꺼내는 것을 좋아합니다. 순서를 반대로 바꾸는 등의 작업을 수행합니다. 여기서 이 작업의 옳고 그름을 논의하지는 않겠지만, 모두가 가장 적절한 시나리오에서 가장 적절한 데이터 구조를 사용할 수 있기를 바랍니다. 가장 적합한 객체를 찾을 수 없다면 다음을 선택하세요. 가장 적절한 유형입니다. 다른 사람이 귀하의 코드를 넘겨받아서 그것이 표준이라는 것을 알게 되면, 이 사람은

뭔가

를 갖고 있다는 것을 알게 됩니다. 그는 귀하가 모든 것에 String을 사용한다는 것을 알게 됩니다.

그래, 이건 모두 여담이야. 습관은 자연스럽고, 작은 습관이 성공을 만든다는 걸 명심하길 바란다.

String의 실제 적용 시나리오는 비교적 광범위합니다.

Cache 함수: String

String은

뿐만 아니라 가장 일반적으로 사용되는 데이터 유형이므로 각 언어가 가장 기본적인 유형입니다.
Redis를 캐시로 사용하고, 다른 데이터베이스를 스토리지 계층으로 사용하고, Redis를 사용하여 높은 동시성을 지원하면 시스템의 읽기 및 쓰기 속도를 크게 높이고 백엔드 데이터베이스에 대한 부담을 줄일 수 있습니다. 카운터:
많은 시스템에서는
를 시스템의 실시간 카운터로 사용하여 계산 및 쿼리 기능을 빠르게 구현할 수 있습니다. 그리고 최종 데이터 결과는 특정 시점에 데이터베이스나 기타 저장 매체에 저장되어 영구 저장될 수 있습니다.
공유 사용자 세션:
사용자가 인터페이스를 새로 고치고 다시 로그인하기 위해 데이터에 액세스하거나 페이지 캐시
에 액세스해야 할 수도 있지만
Redis를 사용하여 사용자의 세션을 중앙에서 관리할 수 있습니다. , 여기 이 모드는 Redis의 고가용성만 보장하면 되며, 사용자 Session의 각 업데이트 및 획득이 빠르게 완료될 수 있습니다. 효율성을 크게 향상시킵니다.

해시:

이것은 Map과 유사한 구조입니다. 이는 일반적으로 객체(이 객체가 다른 객체를 중첩하지 않는 경우)와 같은 구조화된 데이터를 에 있습니다. Redis, 캐시를 읽거나 쓸 때마다 Hash의 특정 필드에서 작업을 수행할 수 있습니다.

그러나 이 시나리오는 실제로는 좀 더 간단합니다. 왜냐하면 현재 많은 객체가 상대적으로 복잡하기 때문입니다. 예를 들어 제품 객체에는 객체를 포함한 많은 속성이 포함될 수 있습니다. 내 사용 사례에서는 그렇게 많이 사용하지 않습니다.

List:

List는 순서가 지정된 목록이며 여전히 이를 사용하여 많은 트릭을 사용할 수 있습니다.

예를 들어 List를 사용하여 팬 목록, 기사 댓글 목록과 같은 일부 목록 유형 데이터 구조를 저장할 수 있습니다.

예를 들어 lrange 명령을 사용하여 특정 닫힌 간격으로 요소를 읽을 수 있고 List 기반으로 페이징 쿼리를 구현할 수 있습니다. 이는 Redis를 기반으로 간단하게 구현할 수 있는 훌륭한 기능입니다. 고성능 페이징 드롭다운 및 연속 페이징을 사용하는 Weibo와 같은 것은 성능이 뛰어나고 페이지별로 액세스할 수 있습니다.

예를 들어 간단한 메시지 대기열을 만들어 List의 헤드에 넣고 List의 엉덩이에서 꺼낼 수 있습니다.

List 자체는 핫 데이터는 말할 것도 없고 개발 과정에서 흔히 사용되는 데이터 구조입니다.

메시지 큐: Redis의 연결 목록 구조는 차단 큐를 쉽게 구현할 수 있으며 left-in 및 right-out 명령을 사용하여 큐 디자인을 완성할 수 있습니다. 예를 들어 데이터 생산자는 Lpush 명령을 통해 왼쪽에서 데이터를 삽입할 수 있으며, 여러 데이터 소비자는 BRpop 명령을 사용하여
BRpop
기사 목록 또는 데이터 페이징 표시를 위한 애플리케이션입니다. 예를 들어, 우리가 흔히 사용하는 블로그 웹사이트의 사용자 수가 늘어나고 각 사용자가 자신만의 기사 목록을 갖고 있으며 기사가 많아 페이지에 표시해야 하는 경우 이 때 사용을 고려할 수 있습니다.
Redis

Set:

Set

은 중복 항목을 자동으로 제거하는 순서가 지정되지 않은 세트입니다. 시스템에서 중복 제거해야 하는 데이터를 Set에 직접 입력하면 자동으로 중복 제거됩니다. 일부 데이터의 전역 중복 제거를 빠르게 수행해야 하는 경우 물론 메모리에서 JVM을 사용할 수도 있습니다. HashSet은 중복 제거를 수행하지만 시스템 중 하나가 여러 시스템에 배포된 경우 어떻게 될까요? 전역 Set 중복 제거는

Redis

를 기반으로 수행되어야 합니다.

Set

을 기반으로 교차, 결합 및 차이 연산을 수행할 수 있습니다. 예를 들어 교차하는 경우 두 사람의 친구 목록을 결합하여 공통 친구가 누구인지 확인할 수 있습니다. 오른쪽. 어쨌든 비교가 빠르고 작업이 간단하기 때문에 이러한 시나리오가 많이 있습니다. 하나의

Set

으로 두 개의 쿼리를 수행할 수 있습니다. Sorted Set:

Sorted set은

Set

로 정렬되며, 중복이 제거되지만 정렬이 가능합니다. 작성 시 점수가 부여되고 점수에 따라 자동으로 정렬됩니다. 주문 세트의 사용 시나리오는 세트와 유사하지만 세트 세트가 자동으로 정렬되지 않는 반면, 정렬 세트는 점수를 사용하여 멤버를 정렬할 수 있으며 삽입 시 정렬됩니다. 따라서 순서가 있고 중복되지 않은 세트 목록이 필요한 경우

Sorted set

가중 대기열을 만들려면
Sorted Set
을 사용하세요. 예를 들어 일반 메시지의 점수는 1이고 중요한 메시지의 점수는 2입니다. 그런 다음 작업자 스레드는 역순으로 작업 작업을 가져오도록 선택할 수 있습니다. 점수의. 중요한 작업의 우선순위를 정하세요.

고급 사용법:

Bitmap

Bitmap은 정보를 비트 단위로 저장하는 것을 지원합니다.

BloomFilter

구현에 사용; HyperLogLog:

은 통계 UV와 같은 대규모 데이터의 중복 제거 통계에 더 적합한 부정확한 중복 제거 계산 기능을 제공합니다. ;Geospatial:

🎜 🎜

지리적 위치를 저장하고 위치 거리를 계산하거나 반경 등을 기준으로 위치를 계산하는 데 사용할 수 있습니다. Redis를 사용하여 주변 사람들을 구현하는 것에 대해 생각해 본 적이 있습니까? 아니면 최적의 지도 경로를 계산하시겠습니까?

이 세 가지는 실제로 데이터 구조로 계산할 수 있습니다. 꿈이 시작된 Redis 기본 유형에 대해 언급 한 것을 아직도 기억하는 친구가 몇 명이나 될까요? 글쎄, 고급 사용법에 대해 이야기할 수 있다면 뭔가 있다고 생각합니다.

pub/sub: 기능은 간단한 메시지 대기열로 사용할 수 있는 구독 게시 기능입니다.

파이프라인: 일련의 명령을 일괄적으로 실행하고 모든 결과를 한 번에 반환할 수 있으므로 빈번한 요청 응답을 줄일 수 있습니다.

Lua:

Redis

은 일련의 기능을 수행하기 위해 Lua 스크립트 제출을 지원합니다. 제가 예전 전자상거래 상사로 근무할 때 플래시 세일 시나리오에서 이 제품을 자주 사용했습니다. 이는 의미가 있고 원자성을 활용합니다.

그나저나 플래시세일 디자인 보실래요? 인터뷰할 때마다 이 질문을 했던 기억이 나네요. 보고 싶으시면

댓글 달아주시면 즉시 할인됩니다.

트랜잭션: 마지막 기능은 트랜잭션인데

Redis

는 엄격한 트랜잭션을 제공하지 않습니다. Redis는 명령의 직렬 실행만 보장하며 모든 실행을 보장할 수 있지만 다음과 같은 경우에는 작동하지 않습니다. 명령 실행이 실패하면 롤백되지만 실행은 계속됩니다.

Persistence

Redis

는 RDB와 AOF라는 두 가지 지속성 방법을 제공합니다. RDB는 메모리에 있는 데이터 세트를 스냅샷 형식으로 디스크에 씁니다. 바이너리 압축 저장소를 사용하여 AOF는 Redis에서 처리되는 모든 쓰기 또는 삭제 작업을 텍스트 로그 형식으로 기록합니다.

RDB

전체 Redis 데이터를 단일 파일에 저장하면 재해 복구에 더 적합합니다. 그러나 단점은 스냅샷이 저장되기 전에 머신이 다운되면 이 기간 동안의 데이터가 손실된다는 것입니다. 또한, 스냅샷을 저장하면 서비스가 잠시 중단될 수 있습니다.

AOF

로그 파일 쓰기 작업에 사용되는 추가 모드는 초당 동기화, 수정당 동기화 및 비동기화를 지원하는 유연한 동기화 전략을 가지고 있습니다. 단점은 동일한 크기의 데이터 세트에 대해 AOF가 더 크다는 것입니다. RDB.AOF RDB보다 운영 효율성이 느린 경우가 많습니다. 자세한 내용은 고가용성 장을 참조하세요. 특히 둘의 장단점, 선택 방법을 살펴보세요.

"Slap the Interviewer" 시리즈 - Redis sentry, persistence, master-slave, hand-shredded LRU

고가용성 Redis의 고가용성을 살펴보겠습니다. Redis는 마스터-슬레이브 동기화를 지원하고 클러스터 클러스터 배포 모드를 제공하며 Sentinel을 통해 Redis 마스터 서버의 상태를 모니터링합니다. 마스터가 실패하면 특정 전략에 따라 슬레이브 노드에서 새 마스터가 선택되고 다른 슬레이브는 새 마스터에 맞게 조정됩니다.

간단히 말하면 마스터를 선택하는 세 가지 전략이 있습니다.

슬레이브의 우선 순위가 낮을수록 우선 순위가 높아집니다.

동일한 상황에서 슬레이브가 복사하는 데이터가 많을수록 우선 순위가 높아집니다. ;
같은 조건 룬디드가 작을수록 선택하기 쉽습니다.
Redis 클러스터에서는 센티널도 여러 인스턴스에 배포되며 센티널은 Raft 프로토콜을 사용하여 고가용성을 보장합니다.

Redis 클러스터는 샤딩 메커니즘을 사용하며 내부적으로 16384개의 슬롯으로 나누어져 있으며, 이는 모든 마스터 노드에 배포됩니다. 각 마스터 노드는 슬롯의 일부를 담당합니다. 데이터 연산 중에 키에 따라 CRC16을 수행하여 어느 슬롯에 있는지, 어느 마스터에서 처리할지 계산합니다. 슬레이브 노드를 통해 데이터 중복성이 보장됩니다.

SentinelSentinel은 견고성을 보장하기 위해 세 개의 인스턴스를 사용해야 합니다. Sentinel+마스터-슬레이브 조합은

데이터가 손실되지 않는다고 보장할 수 없지만

클러스터의 고가용성을 보장할 수 있습니다. 왜 세 개의 인스턴스가 필요한가요? 먼저 두 보초에게 무슨 일이 일어나는지 봅시다.

그럼 이게 뭐가 문제인가요? M1이 다운되면 S1이 다운되지 않으면 괜찮지만, 머신 전체가 다운되면 어떻게 될까요? 남은 센티널은 S2뿐이고, 다른 머신에 R1이 있어도 페일오버를 허용하는 센티널이 없습니다.

클래식 Sentinel 클러스터는 다음과 같습니다.

여러분, sentinel 구성 요소의 주요 기능을 간략하게 요약하겠습니다.

클러스터 모니터링: Redis 마스터 및 슬레이브 프로세스가 정상적으로 작동하는지 모니터링하는 역할을 담당합니다.
메시지 알림: Redis 인스턴스가 실패하면 Sentinel은 관리자에게 경보 알림 메시지를 보낼 책임이 있습니다.
페일오버: 마스터 노드가 중단되면 자동으로 슬레이브 노드로 전환됩니다.
구성 센터: 장애 조치가 발생하면 클라이언트에 새 마스터 주소를 알립니다.

Master-slave

이 이것을 언급했는데, 앞서 언급한 데이터 지속성 RDB 및 AOF과 밀접한 관련이 있습니다.

마스터-슬레이브 아키텍처 모델을 사용해야 하는 이유에 대해 먼저 이야기하겠습니다. 앞서 언급했듯이 단일 머신 QPS에는 상한이 있으며 Redis의 특징은 높은 읽기 동시성을 지원해야 한다는 것입니다. 그렇다면 그는 또한 누가 이것을 견딜 수 있습니까?라고 썼습니다. 하지만 이 마스터 머신에 쓰기를 허용하고 데이터를 다른 슬레이브 머신에 동기화하여 모두가 이를 사용하여 읽는다면 많은 요청을 분산시키는 것이 훨씬 좋지 않을까요? 용량을 확장할 때 수평 확장이 가능합니다. 쉽게 달성됩니다.

슬레이브를 시작하면 psync 명령이 마스터에 전송됩니다. 이 슬레이브가 처음으로 마스터에 연결되면 전체 복사가 실행됩니다. 마스터는 스레드를 시작하고, RDB 스냅샷을 생성하고, 새로운 쓰기 요청을 메모리에 캐시합니다. RDB 파일이 생성된 후 마스터는 이 RDB를 슬레이브에 보내고 슬레이브는 이 작업을 수행합니다. 가장 먼저 할 일은 이를 로컬 디스크에 쓴 다음 메모리에 로드하는 것입니다. 그런 다음 마스터는 메모리에 캐시된 모든 새 이름을 슬레이브에 보냅니다.

제가 게시한 후 CSDN의 네티즌: Jian_Shen_Zer가 다음과 같은 질문을 했습니다.

마스터-슬레이브 동기화 중에 새 슬레이브가 들어오면 후속 데이터는 어떻게 되나요? 새로운 데이터가 마스터에 입력되면 어떻게 슬레이브와 동기화할 수 있습니까? Ao Bing이 대답했습니다: 멍청해요,

AOF

, 증가는 MySQL의 Binlog과 같습니다. 로그 증가를 슬레이브에 동기화하면 됩니다. service

키 만료 메커니즘

Redis

키는 만료 시간을 설정할 수 있습니다. Redis는 만료 후 능동 및 수동 만료 메커니즘을 조합하여 사용하며, 다른 하나는 MC와 같이 액세스 중에 수동 삭제를 실행하는 것입니다. 정기적으로 적극적으로 삭제합니다. 주기적 + 게으른 + 메모리 제거

캐싱 FAQ

캐시 업데이트 방법캐시 사용을 결정할 때 고려해야 할 문제입니다.

데이터 소스가 변경되면 캐시된 데이터를 업데이트해야 합니다. 데이터 소스는 DB일 수도 있고 원격 서비스일 수도 있습니다. 업데이트 방법은 활성 업데이트일 수 있습니다. 데이터 소스가 DB인 경우, DB 업데이트 후 바로 캐시 업데이트가 가능합니다.

데이터 소스가 DB가 아닌 다른 원격 서비스의 경우 시간에 따른 데이터 변화를 적극적으로 감지하지 못할 수 있습니다. 이 경우 일반적으로 캐시된 데이터에 대한 만료 날짜를 설정하도록 선택합니다. 이는 최대 허용 시간입니다. 데이터 불일치 때문입니다.

이 시나리오에서는 무효화 업데이트를 선택할 수 있습니다. 키가 존재하지 않거나 유효하지 않은 경우 먼저 데이터 소스에 최신 데이터를 가져온 다음 다시 캐시하고 만료 날짜를 업데이트하세요.

하지만 여기에 문제가 있습니다. 업데이트 중에 종속 원격 서비스에서 예외가 발생하면 데이터를 사용할 수 없게 됩니다. 개선된 방법은 비동기식 업데이트로, 만료 시 데이터가 지워지지 않고 기존 데이터가 계속 사용된 후 비동기 스레드가 업데이트 작업을 수행하는 방식입니다. 이는 실패 순간의 창 기간을 방지합니다. 정기적으로 일괄적으로 데이터를 업데이트하는 순수 비동기식 업데이트 방법도 있습니다. 실제 사용 시 비즈니스 시나리오에 따라 업데이트 방법을 선택할 수 있습니다.

데이터 불일치두 번째 문제는 데이터 불일치 문제입니다. 캐시를 사용하는 한 이 문제에 어떻게 대처할지 고려해야 한다고 할 수 있습니다. 캐시 불일치의 원인은 일반적으로 활성 업데이트 실패입니다. 예를 들어, DB를 업데이트한 후 네트워크 문제 또는 비동기 업데이트 실패로 인해

Redis

에 대한 업데이트 요청 시간이 초과됩니다. 해결책은 서비스가 시간 소모에 특별히 민감하지 않은 경우 재시도를 추가할 수 있다는 것입니다. 서비스가 시간 소모에 민감한 경우 실패한 업데이트는 비동기 보상 작업을 통해 처리되거나 단기적인 데이터 불일치가 발생합니다. 비즈니스에 영향을 미치지 않으면 다음 업데이트까지 첫 번째 업데이트 동안 성공할 수 있으며 최종 일관성이 보장될 수 있습니다.

캐시 침투

. 이러한 문제의 원인은 외부의 악의적인 공격일 수 있는데, 예를 들어 사용자 정보를 캐싱했지만 악의적인 공격자가 존재하지 않는 사용자 ID를 사용하여 인터페이스를 자주 요청하여 쿼리 캐시가 누락된 후 DB를 통해 쿼리되는 경우가 있습니다. 아직도 그리워요. 이때, DB에 접근하기 위해 캐시를 관통하는 요청이 많아지게 됩니다.

해결 방법은 다음과 같습니다.

존재하지 않는 사용자의 경우 동일한 ID가 다시 DB에 접근하는 것을 방지하기 위해 캐시에 빈 개체를 저장하여 표시합니다. 그러나 때로는 이 방법으로도 문제가 잘 해결되지 않고, 캐시에 쓸모없는 데이터가 대량으로 저장되는 경우가 있습니다.

BloomFilter 필터를 사용하세요. BloomFilter는 BloomFilter에 없으면 데이터가 존재하지 않아야 하며, BloomFilter에 있으면 실제 데이터가 존재하지 않을 수 있습니다. 이런 종류의 문제를 해결하는 데 매우 적합합니다.

캐시 분석

캐시 분석은 특정 핫 데이터에 오류가 발생하면 이 데이터에 대한 많은 요청이 데이터 소스에 침투한다는 의미입니다.

이 문제를 해결하는 방법은 다음과 같습니다.

뮤텍스 잠금 업데이트를 사용하면 동일한 프로세스가 동일한 데이터를 DB에 동시에 요청하지 않도록 하여 DB 부담을 줄일 수 있습니다.

무작위 백오프 방법을 사용하세요. 실패하면 짧은 시간 동안 무작위로 절전 모드로 전환되고, 실패하면 다시 쿼리하고 업데이트를 수행합니다.

여러 핫스팟 키가 동시에 실패하는 문제를 해결하려면 캐싱 시 고정 시간과 작은 난수를 사용하여 동시에 많은 수의 핫스팟 키가 실패하는 것을 방지할 수 있습니다.

Cache avalanche

Cache avalanche, 이유는 캐시가 중단되고 모든 요청이 DB에 침투하기 때문입니다.

해결책:

빠른 실패 회로 차단기 전략을 사용하여 DB에 대한 즉각적인 압력을 줄입니다.

마스터-슬레이브 모드와 클러스터 모드를 사용하여 캐시 서비스의 고가용성을 보장합니다.

실제 시나리오에서는 이 두 가지 방법이 함께 사용됩니다.

오래된 친구들은 제가 길게 소개하지 않은 이유를 다 알고 있습니다 여기서 몇 가지만 말씀드리자면 제가 이전에 쓴 글이 정말 너무 자세해서 좋아요하지 않을 수 없었습니다. 여기에 반복해서 복사하세요.

"Hit the Interviewer" 시리즈 - Redis 기본

"Hit the Interviewer" 시리즈 - 캐시 눈사태, 고장, 침투

"Hit the Interviewer" 시리즈 - Redis Sentinel, 지속성 변환, 마스터-슬레이브 , 핸드파쇄 LRU

"면접관을 물리치다" 시리즈 - 레디스 최종장 - 겨울이 온다, FPX - 신왕 즉위

테스트 포인트 및 보너스 포인트

Get it Take 메모!

테스트 포인트

인터뷰 중 캐싱에 대해 질문하겠습니다. 주로 캐싱 기능에 대한 이해도와 MC 및 Redis의 특성과 사용법에 대한 숙달 여부를 테스트하기 위한 것입니다.

캐시 사용 시나리오와 다음과 같은 다양한 유형의 캐시를 사용하는 방법을 알아야 합니다.

-DB 캐시 종속 서비스를 줄여 동시성 성능을 향상시키는 캐시 DB 핫 데이터;
- 순수 K-V 캐싱 시나리오의 경우
MC
를 사용할 수 있습니다. 목록 및 집합과 같은 특수 데이터 형식을 캐시해야 하는 경우
Redis를 사용하면 순위 데이터를 저장하고 계산해야 하는 경우 zset를 사용할 수 있습니다. Redis의 구조를 저장합니다.

원자적 증가 및 감소, 다양한 데이터 구조에서 작동하는 명령 등 MC와 Redis의 일반적인 명령을 이해합니다.

MC와 메모리 내
Redis
의 저장 구조를 이해하면 사용 용량을 평가하는 데 도움이 됩니다.
적극적으로 트리거된 주기적 컬링 및 수동적으로 트리거된 지연 컬링과 같은 MC 및
Redis
의 데이터 오류 방법 및 컬링 전략을 이해합니다.

의 지속성, 마스터-슬레이브 동기화 및
Cluster
배포를 이해합니다. RDB과
AOF
간의 구현 방법 및 차이점과 같은 Redis
원칙.
캐시 침투, 고장 및 눈사태의 유사점, 차이점 및 해결책을 알아야 합니다. 전자상거래 경험이 있든 없든, 플래시세일의 구체적인 구현 방법과 세부 사항을 알아야 한다고 생각합니다.

…..

보너스 포인트

면접에서 더 나은 성과를 내고 싶다면 다음 보너스 포인트도 알아두세요.

은 실제 적용 시나리오를 기반으로 캐시의 사용법을 소개합니다. 예를 들어 정보를 얻기 위해 백엔드 서비스 인터페이스를 호출할 때 로컬 + 원격 다단계 캐시를 사용할 수 있으며, 동적 순위 시나리오의 경우 Redis의 Sorted set
을 사용하여 이를 달성하는 등을 고려할 수 있습니다.

프로젝트에서 어떤 시나리오에서 Redis를 사용했는지, 어떤 데이터 구조가 사용되었는지, MC를 사용할 때 어떤 유형의 문제가 해결되었는지 등 분산 캐시 설계 및 사용 경험이 있으면 가장 좋습니다. 추정값에 따라 조정 McSlab 매개변수 등을 할당합니다.

캐시 사용시 발생할 수 있는 문제를 이해하시는 것이 가장 좋습니다. 예를 들어 Redis는 단일 스레드 처리 요청입니다. 시간이 많이 걸리는 단일 요청 작업은 상호 영향을 방지하기 위해 최대한 피해야 합니다. Redis 서비스는 다른 CPU 집약적인 프로세스와 동일한 시스템에 배포되지 않아야 합니다. ; 또는 스왑 메모리 교환을 비활성화해야 합니다. Redis의 캐시된 데이터가 하드 디스크로 교환되어 성능에 영향을 미치는 것을 방지하세요. 또 다른 예는 앞서 언급한 MC 석회화 문제입니다.

예를 들어 Redis의 일반적인 애플리케이션 시나리오를 이해하려면 Redis를 사용하여 분산 잠금을 구현하고 Bitmap을 사용하여 BloomFilter을 구현하고 HyperLogLog를 사용하여 UV 통계 등을 수행합니다.

모듈 시스템을 통한 맞춤형 기능 확장을 지원하는 영구 메시지 대기열 스트림 등 Redis 4.0 및 5.0의 새로운 기능을 알아보세요.

……..

더 많은 프로그래밍 관련 지식을 보려면 프로그래밍 비디오를 방문하세요! !

위 내용은 Redis에 대한 일반적인 인터뷰 질문 요약(답변 분석 포함)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!