꼭 알아야 할 Redis 인터뷰 질문 20개 이상 요약, 와서 모아보세요! !-Redis-php.cn

이 기사에서는 차이점을 확인하고 지식을 향상할 수 있도록 Redis 인터뷰 질문 몇 가지를 공유하겠습니다. 도움이 필요한 친구들이 모두 참고할 수 있기를 바랍니다.

꼭 알아야 할 Redis 인터뷰 질문 20개 이상 요약, 와서 모아보세요! !

애플리케이션 시나리오

Cache
공유 세션
메시지 대기열 시스템
분산 잠금

관련 추천: Redis 비디오 튜토리얼

single Why Redis는 빠르게 스레드됩니다

순수한 메모리 작업
단일 스레드 작업, 빈번한 컨텍스트 전환 방지
합리적이고 효율적인 데이터 구조
비차단 I/O 다중화 메커니즘 사용(파일 1개) descriptor는 데이터 도착을 위해 동시에 여러 파일 설명자를 모니터링합니다)

Redis 데이터 구조 및 사용 시나리오

String string: 문자열 유형은 Redis 구조의 가장 기본적인 데이터이며, 우선 키 문자열 유형이며, 기타 여러 데이터 구조는 문자열 유형을 기반으로 구축됩니다. 우리가 자주 사용하는 키 값 설정 명령은 문자열입니다. 캐싱, 계산, 공유 세션, 속도 제한 등에 일반적으로 사용됩니다.
Hash: Redis에서 해시 유형은 키-값 쌍 구조인 키 값 자체를 의미합니다. 해시는 장바구니 구현과 같은 사용자 정보를 저장하는 데 사용할 수 있습니다.
리스트(이중 연결 리스트): 리스트(리스트) 유형은 순서가 지정된 여러 문자열을 저장하는 데 사용됩니다. 간단한 메시지 큐 기능을 수행할 수 있습니다.
Set: 집합 유형은 여러 문자열 요소를 저장하는 데에도 사용되지만 목록 유형과 달리 집합에 중복된 요소는 허용되지 않으며 집합에 있는 요소는 인덱스 첨자로 검색할 수 없습니다. 집합의 교집합, 합집합, 차이 및 기타 연산을 사용하여 공통 선호도, 모든 선호도, 고유한 선호도 및 기타 기능을 계산할 수 있습니다.
Sorted Set(점프 목록 구현): Sorted Set에는 추가 가중치 매개변수 Score가 있으며, Set의 요소는 Score에 따라 정렬될 수 있습니다. TOP N 연산을 수행하기 위한 순위 애플리케이션으로 사용할 수 있습니다.

Redis의 데이터 만료 전략

Redis의 데이터 만료 전략은 정기 삭제 + 지연 삭제 전략

정기 삭제 전략을 채택합니다. Redis는 타이머를 사용하여 모든 키를 정기적으로 모니터링하여 키가 삭제되었는지 확인합니다. 만료되었습니다. 만료되면 삭제하세요. 이 전략은 만료된 키가 결국 삭제되도록 보장할 수 있지만 심각한 단점도 있습니다. 매번 메모리의 모든 데이터를 탐색하여 많은 CPU 리소스를 소비하고, 키가 만료되었지만 타이머가 여전히 작동하는 경우입니다. 깨어나지 않은 상태에서는 이 시간 동안에도 키를 사용할 수 있습니다.
지연 삭제 전략: 키를 얻을 때 먼저 키가 만료되었는지 확인하고 만료되면 삭제합니다. 이 방법에는 단점이 있습니다. 키가 사용되지 않은 경우 실제로는 만료되어 많은 공간을 낭비하게 됩니다.
이 두 가지 전략은 자연스럽게 상호보완적이며, 예약된 삭제 전략은 더 이상 매번 모든 키를 검사하지 않고 검사를 위해 키의 일부를 무작위로 선택하여 위험을 줄입니다. CPU 리소스 소비 및 지연 삭제 전략은 확인되지 않은 키를 보완하고 기본적으로 모든 요구 사항을 충족합니다. 하지만 때로는 타이머에 의해 추출되지도 않고 사용되지도 않는 우연의 일치일 때도 있습니다. 어떻게 이 데이터가 메모리에서 사라지나요? 중요하지 않습니다. 메모리 제거 메커니즘도 있습니다. 메모리가 충분하지 않으면 메모리 제거 메커니즘이 작동합니다. 제거 전략은 다음과 같이 나뉩니다. 메모리가 새로 작성된 데이터를 수용하기에 충분하지 않은 경우 새 쓰기 작업에서 오류가 보고됩니다. (Redis 기본 정책) 새로 작성된 데이터를 수용할 만큼 메모리가 부족한 경우 키 공간에서 가장 최근에 사용된 키를 제거합니다. (LRU 권장) 새로 작성된 데이터를 수용할 만큼 메모리가 부족할 경우 키 공간에서 키를 무작위로 제거합니다. 새로 작성된 데이터를 수용할 만큼 메모리가 부족한 경우 만료 시간이 설정된 키 공간에서 가장 최근에 사용된 키가 제거됩니다. 이 상황은 일반적으로 Redis가 캐시와 영구 저장소로 사용될 때 사용됩니다. 새로 작성된 데이터를 수용할 만큼 메모리가 부족한 경우 만료 시간이 설정된 키가 키 공간에서 무작위로 제거됩니다. 새로 작성된 데이터를 수용할 만큼 메모리가 부족한 경우 만료 시간이 설정된 키 공간에서 만료 시간이 더 빠른 키가 먼저 제거됩니다.

Redis의 Redis set 및 setnx

setnx는 만료 시간 설정을 지원하지 않습니다. 분산 잠금을 수행할 때 특정 클라이언트 중단으로 인한 교착 상태를 방지하려면 잠금 만료 시간을 설정해야 합니다. 높은 동시성에서는 setnx 및 만료가 원자성 작업을 구현할 수 없습니다. 이를 사용하려면 프로그램 코드에서 이를 명시적으로 잠가야 합니다. SETNX 대신 SET을 사용하는 것은 SETNX+EXPIRE가 원자성을 달성하는 것과 동일합니다. SETNX 성공 및 EXPIRE 실패에 대해 걱정할 필요가 없습니다.

Redis의 특정 LRU 구현:

기존 LRU는 스택을 사용하며 매번 최신에 사용된 데이터를 스택의 맨 위로 이동합니다. 그러나 스택을 사용하면 많은 양의 핫하지 않은 데이터가 스택으로 이동하게 됩니다. select *.data 실행시 헤드를 차지하므로 개선이 필요합니다. Redis는 키로 값을 얻을 때마다 값의 lru 필드를 현재 두 번째 수준 타임스탬프로 업데이트합니다. Redis의 초기 구현 알고리즘은 매우 간단합니다. dict에서 5개의 키를 무작위로 가져오고 lru 필드 값이 가장 작은 키를 제거합니다. 3.0에서는 또 다른 버전의 알고리즘이 개선되었습니다. 먼저 무작위로 선택된 첫 번째 키가 풀(풀의 크기는 16)에 저장됩니다. 다음으로, 무작위로 선택된 각 keylru 값은 풀이 가득 찰 때까지 계속 추가되기 전에 풀에서 가장 작은 lru보다 작아야 합니다. 가득 찬 후에는 새 키를 넣어야 할 때마다 풀에서 가장 큰 lru를 가진 키를 꺼내야 합니다. 제거할 때는 풀에서 가장 작은 lru 값을 직접 선택하여 제거합니다.

Redis가 핫스팟 키를 발견하는 방법

경험을 활용하여 예측: 예를 들어 활동 시작을 미리 알고 있는 경우 이 키를 핫스팟 키로 사용합니다.
서버측 수집: Redis를 실행하기 전, 데이터 통계를 위한 코드 한 줄을 추가합니다.
평가를 위한 패킷 캡처: Redis는 TCP 프로토콜을 사용하여 클라이언트와 통신합니다. 통신 프로토콜은 RESP를 사용하므로 포트를 모니터링하는 자체 프로그램을 작성하여 분석을 위해 패킷을 가로챌 수도 있습니다.
프록시 계층에서는 각 Redis 요청이 수집되고 보고됩니다.
Redis에는 명령 쿼리가 제공됩니다. Redis4.0.4 버전은 단축키를 찾을 수 있는 redis-cli –hotkeys를 제공합니다. (Redis에 내장된 명령을 사용하여 쿼리하려면 먼저 메모리 제거 정책을 allkeys-lfu 또는 휘발성-lfu로 설정해야 합니다. 그렇지 않으면 오류가 반환됩니다. Redis를 입력하고 config set을 사용하세요. maxmemory-policy allkeys-lfu.)

Redis의 핫스팟 키 솔루션

서버 측 캐싱: 핫스팟 데이터를 서버 메모리에 캐싱(Redis의 자체 메시지 알림 메커니즘을 사용하여 데이터 Redis 및 서버 측 핫스팟 키 일관성, 클라이언트는 핫스팟 키에 대한 모니터를 설정합니다. 핫스팟 키가 업데이트되면 서버도 이를 업데이트합니다. )
핫스팟 키, 즉 핫스팟 키를 백업합니다. + 난수는 다른 Redis 노드에 무작위로 배포됩니다. 이런 방식으로 핫스팟 키에 액세스할 때 모든 키가 동일한 시스템에 도달하지 않습니다.

Redis 캐시 사태 문제를 해결하는 방법

Redis 고가용성 아키텍처 사용: Redis 클러스터를 사용하여 Redis 서비스가 중단되지 않도록 하세요
캐시 시간이 일치하지 않습니다. 캐시 만료 시간 집단적 실패를 피하기 위한 무작위 값
현재 제한 다운그레이드 전략: 특정 파일링이 있습니다. 예를 들어 개인화 추천 서비스를 사용할 수 없는 경우 핫스팟 데이터 추천 서비스로 대체합니다

방법. Redis 캐시 침투 문제를 해결하려면

인터페이스에서 확인
null 값 저장(캐시 분석 및 잠금 또는 만료되지 않도록 설정)
Bloom 필터 차단: 가능한 모든 쿼리 키를 Bloom 필터를 먼저 쿼리할 때 Bloom 필터에 키가 존재하는지 먼저 확인한 후, 존재하지 않으면 아래쪽으로 계속 실행합니다. Bloom 필터는 값을 여러 해시 비트에 저장합니다. Bloom 필터가 특정 요소가 존재한다고 말하면 잘못 판단될 수 있습니다. Bloom 필터에 요소가 없다고 표시되면 해당 요소는 거기에 없어야 합니다.

Redis의 지속성 메커니즘

Redis는 효율성을 보장하기 위해 데이터를 메모리에 캐시하지만 업데이트된 데이터를 주기적으로 디스크에 쓰거나 수정 작업을 추가 레코드 파일에 기록하여 데이터 지속성을 보장합니다. Redis에는 두 가지 지속성 전략이 있습니다.

RDB: 스냅샷 형식은 메모리에 있는 데이터를 덤프 파일로 직접 저장하고 정기적으로 저장하며 전략을 저장하는 것입니다. Redis를 지속해야 하는 경우 Redis는 하위 프로세스를 포크하고 하위 프로세스는 디스크의 임시 RDB 파일에 데이터를 씁니다. 하위 프로세스가 임시 파일 쓰기를 완료하면 원본 RDB를 교체합니다.
AOF: Redis 서버를 수정하기 위한 모든 명령을 명령 모음인 파일로 저장합니다.

지속성을 위해 AOF를 사용하세요. 각 쓰기 명령은 쓰기 기능을 통해appendonly.aof에 추가됩니다. aof의 기본 정책은 초당 한 번씩 fsync하는 것입니다. 이 구성에서는 오류가 발생하더라도 최대 1초 동안 데이터가 손실됩니다. 단점은 동일한 데이터 세트의 경우 AOF의 파일 크기가 일반적으로 RDB 파일의 크기보다 크다는 것입니다. 사용된 fsync 전략에 따라 AOF는 RDB보다 느릴 수 있습니다. Redis는 기본적으로 스냅샷 RDB의 지속성 방법을 사용합니다. 마스터-슬레이브 동기화는 마스터-슬레이브가 방금 연결되었을 때 전체 동기화(RDB)를 수행하고, 전체 동기화가 완료된 후 증분 동기화(AOF)를 수행합니다.

Redis 트랜잭션

Redis 트랜잭션의 핵심은 명령 집합입니다. 트랜잭션은 한 번에 여러 명령 실행을 지원하며 트랜잭션의 모든 명령은 직렬화됩니다. 트랜잭션 실행 프로세스 중에 대기열의 명령은 직렬화되어 순서대로 실행되며 다른 클라이언트가 제출한 명령 요청은 트랜잭션 실행 명령 시퀀스에 삽입되지 않습니다. 요약하자면, Redis 트랜잭션은 대기열에 있는 일련의 명령을 일회성, 순차적, 배타적으로 실행하는 것입니다.
Redis 트랜잭션에는 격리 수준 개념이 없습니다. 일괄 작업은 EXEC 명령을 보내기 전에 대기열 캐시에 저장되며 실제로 실행되지 않습니다. 따라서 트랜잭션 내에서 업데이트를 확인할 수 있는 쿼리가 없습니다. 거래 외부에서 쿼리를 볼 수 없습니다.
Redis에서는 단일 명령이 원자적으로 실행되지만 트랜잭션은 원자성이 보장되지 않으며 롤백도 없습니다. 트랜잭션의 명령 중 하나라도 실행이 실패하더라도 나머지 명령은 계속 실행됩니다.

Redis 트랜잭션 관련 명령

watch key1 key2 ... : 트랜잭션이 실행되기 전에 모니터링되는 키가 다른 명령에 의해 변경되면 트랜잭션이 중단됩니다(예: 낙관적 잠금)
multi: 트랜잭션 블록의 시작을 표시(대기)
exec: 모든 트랜잭션 블록의 명령 실행(exec가 실행되면 이전에 추가된 모니터링 잠금이 취소됨)
폐기: 트랜잭션 취소, 트랜잭션 블록의 모든 명령 포기
unwatch: 시계의 모든 키 모니터링 취소

Redis와 memcached의 차이점

저장 방법 측면에서: memcache는 모든 데이터를 메모리에 저장하면 정전 후 중단되며 데이터는 메모리 크기를 초과할 수 없습니다. Redis의 일부 데이터는 하드 디스크에 저장되어 데이터의 내구성을 보장합니다.
데이터 지원 유형 측면에서: memcache는 데이터 유형을 간단하게 지원하고 간단한 키-값만 지원하는 반면, redis는 5가지 데이터 유형을 지원합니다.
기본 모델이 다릅니다. 클라이언트와의 통신을 위한 기본 구현 방법과 애플리케이션 프로토콜이 다릅니다. Redis는 자체 VM 메커니즘을 직접 구축했습니다. 일반 시스템이 시스템 기능을 호출하면 이동 및 요청에 일정 시간이 낭비되기 때문입니다.
값 크기: redis는 1GB에 도달할 수 있지만 Memcache는 1MB에 불과합니다.

Redis의 여러 클러스터 모드

Master-slave 복제
Sentinel 모드
cluster 모드

Redis의 Sentinel 모드

Sentinel은 분산 시스템입니다. 마스터-슬레이브 복제를 사용하면 아키텍처에서 여러 개의 센티널 프로세스를 실행할 수 있습니다. 이러한 프로세스는 루머 프로토콜을 사용하여 마스터가 오프라인인지 여부에 대한 정보를 수신하고 투표 프로토콜을 사용하여 자동 장애 조치를 수행할지 여부와 선택할 슬레이브를 결정합니다. 새로운 마스터.

각 센트리는 정기적으로 다른 센티넬, 마스터, 슬레이브에게 메시지를 보내 상대방이 살아 있는지 확인합니다. 상대방이 지정된 시간(구성 가능) 내에 응답하지 않은 것으로 확인되면 임시로 간주됩니다. (소위 "기계가 다운되었다는 주관적 믿음").

"Sentinel Group"의 대부분의 센티널이 특정 마스터가 응답하지 않는다고 보고하면 시스템은 특정 투표 알고리즘을 통해 해당 마스터를 "완전히 죽은"(즉, 객관적으로 실제 다운 머신) 것으로 간주합니다. 시스템은 나머지 노드 중에서 마스터를 선택하고 마스터로 승격할 노드를 선택한 다음 관련 구성을 자동으로 수정합니다.

Redis의 rehash

Redis의 rehash 작업은 일회성 및 중앙 집중식 방식으로 완료되지 않고 여러 단계로 완료됩니다. Redis는 rehash 진행 상황을 표시하기 위해 인덱스 카운터 변수 rehashidx를 유지 관리합니다.

이 점진적 재해시는 중앙 집중식 재해시로 인해 발생하는 엄청난 양의 계산 및 메모리 작업을 방지하지만, redis가 재해시될 때 일반 액세스 요청은 해시 테이블에 두 번(ht[ 0], ht[1]) 액세스해야 할 수도 있다는 점에 유의해야 합니다. 예를 들어 키 값이 새 ht1로 다시 해시되는 경우 먼저 ht0에 액세스해야 합니다. ht0에서 찾을 수 없으면 ht1로 이동하여 찾습니다.

Redis 해시 테이블 확장 조건

해시 테이블에 저장된 키 개수가 해시 테이블 크기를 초과했습니다.
Redis 서버는 현재 BGSAVE 명령(rdb)을 실행하고 있지 않습니다. ) 또는 BGREWRITEAOF 명령이고 해시 테이블의 로드 계수가 1보다 크거나 같습니다.
Redis 서버는 현재 BGSAVE 명령(rdb) 또는 BGREWRITEAOF 명령을 실행 중이며 해시 테이블의 로드 계수는 1입니다. 5보다 크거나 같습니다. (로드 팩터 = 저장된 해시 테이블 노드 수/해시 테이블 크기, 해시 테이블의 로드 팩터가 0.1 미만인 경우 해시 테이블에 축소 작업을 수행합니다.)

Redis 동시 경쟁 키에 대한 솔루션

분산 잠금 + 시간 클릭
메시지 대기열 사용

Redis 파이프라인

단일 스레드 차단 Redis의 경우 파이프라인은 일괄 작업을 충족하고 지속적으로 보낼 수 있습니다. 여러 명령을 Redis 서버에 보낸 다음 응답 결과를 하나씩 구문 분석합니다. 파이프라이닝은 일괄 처리 성능을 향상시킬 수 있습니다. 개선의 주된 이유는 TCP 연결에서 "상호작용 왕복" 시간이 단축된다는 것입니다. 파이프라인의 맨 아래 계층은 모든 작업을 스트림으로 캡슐화하고 redis는 자체적으로 들어오고 나가는 출력 스트림을 정의합니다. sync() 메서드에서 작업을 수행합니다. 각 요청은 대기열에 배치되고 응답 패킷이 구문 분석됩니다.