Redis Cache에 대한 인터뷰 질문을 요약하고 공유합니다.-Redis-php.cn

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

Redis Cache에 대한 인터뷰 질문을 요약하고 공유합니다.

redis 캐시 인터뷰 질문

1. redis와 memcached의 차이점은 무엇인가요? 높은 동시성에서 단일 스레드 Redis가 다중 스레드 Memcached보다 더 효율적인 이유는 무엇입니까?

차이:

memcached는 사진과 비디오를 캐시할 수 있습니다. Redis는 k/v 외에 더 많은 데이터 구조를 지원합니다.
redis는 가상 메모리를 사용할 수 있고, 재해 복구도 가능하며, redis는 마스터-슬레이브를 통해 데이터 백업을 지원합니다.

3. .

이유: memcached 멀티스레딩 모델은 캐시 일관성과 잠금을 도입하고 잠금은 성능 손실을 가져옵니다.

2. Redis 마스터-슬레이브 복제는 어떻게 구현되나요? Redis 클러스터 모드를 구현하는 방법은 무엇입니까? Redis의 키는 어떻게 처리됩니까?

마스터-슬레이브 복제 구현: 마스터 노드는 자체 메모리에 있는 데이터의 스냅샷을 찍어 슬레이브 노드에 전송하고, 슬레이브 노드는 데이터를 메모리에 복원합니다. 이후 새로운 데이터가 추가될 때마다 마스터 노드는 mysql과 유사한 바이너리 로그 형식으로 슬레이브 노드에 명령문을 보내고, 슬레이브 노드는 마스터 노드가 보낸 명령문을 받아 재생한다. +

Redis-cluster 본체 RedisCluster의 여러 노드에 데이터를 자동으로 분산시키는 기능을 제공합니다. 전체 데이터 컬렉션의 특정 데이터 하위 집합이 어느 노드에 저장되는지는 사용자에게 투명합니다.)

redis-cluster 샤딩 원칙: 있음 클러스터의 16384입니다. 슬롯(가상 슬롯)의 길이는 0~16383입니다. 각 마스터 노드는 슬롯의 일부를 담당합니다. 마스터가 담당하는 슬롯에 특정 키가 매핑되면 마스터는 이 키에 대한 서비스를 제공할 책임이 있습니다. 슬롯은 사용자가 지정하거나 초기화 시 자동으로 생성되며 마스터만이 슬롯의 소유권을 갖습니다. 마스터 노드는 16384/8바이트 비트 시퀀스를 유지합니다. 마스터 노드는 비트를 사용하여 특정 슬롯을 소유하는지 여부를 식별합니다. 예를 들어, 슬롯 번호가 1인 경우 마스터는 시퀀스의 두 번째 비트(0부터 시작하는 인덱스)가 1인지 여부만 확인하면 됩니다. 이 구조를 사용하면 노드를 쉽게 추가하거나 제거할 수 있습니다. 예를 들어 새 노드 D를 추가하려면 노드 A, B, C에서 D로 일부 슬롯을 가져와야 합니다.
[관련 권장 사항:
Redis 비디오 튜토리얼
3. Redis를 사용하여 분산 잠금을 설계하는 방법은 무엇입니까? 구현 아이디어에 대해 말씀해주세요. zk를 사용할 수 있나요? 그것을 달성하는 방법? 이 둘의 차이점은 무엇인가요?
redis:
Thread Asetnx(잠긴 객체가 시간 초과될 때의 타임스탬프 tl), true가 반환되면 잠금이 획득됩니다.
스레드 B는 get을 사용하여 t1을 현재 타임스탬프와 비교하고 시간이 초과되었는지 확인합니다. 시간이 초과되면 3단계로 이동합니다. 새로운 시간 초과 시간 t2, getset 명령을 사용하여 t3을 반환합니다(이 값은 다른 스레드에 의해 수정되었을 수 있습니다). t1==t3인 경우 잠금이 획득됩니다. t1!=t3인 경우 다른 스레드가 잠금을 획득합니다.
잠금을 획득한 후 비즈니스 로직을 처리한 다음 잠금 시간이 초과되었는지 확인합니다. 시간 초과되지 않은 경우 잠금을 삭제합니다. 다른 스레드의 잠금 삭제를 방지합니다.

zk:

클라이언트가 메소드를 잠그면 zk의 메소드에 해당하는 지정된 노드의 디렉토리에 고유한 순간 순서 노드 node1이 생성됩니다.

클라이언트가 모든 하위 항목을 얻습니다. 자신이 생성한 node1의 일련번호가 가장 작은 것으로 확인되면 클라이언트가 잠금을 획득한 것으로 간주됩니다.

node1이 가장 작지 않은 것으로 확인되면 자신이 만든 노드보다 일련 번호가 작은 가장 큰 노드를 듣고 기다립니다.
락 획득 후 로직 처리를 마치고 생성한 node1을 삭제합니다. 차이점: zk의 성능은 더 나쁘고 오버헤드가 높으며 구현이 간단합니다.
4. Redis의 지속성을 아시나요? 하단 레이어는 어떻게 구현되나요? 장점과 단점은 무엇입니까?
RDB(RedisDataBase: Redis 데이터에 의해 생성된 스냅샷을 다양한 시점의 디스크 및 기타 미디어에 동기화): 메모리에서 하드 디스크로의 스냅샷이 정기적으로 업데이트됩니다. 단점: 시간 소모적, 성능 소모적(fork+io 작업), 데이터 손실이 쉬움.

bgsave는 전체 이미지 지속성을 수행하고 aof는 증분 지속성을 수행합니다. bgsave는 시간이 오래 걸리고 실시간이 아니기 때문에 종료 중에 많은 데이터 손실이 발생하고 redis 인스턴스가 다시 시작되면 aof가 먼저 사용되어 메모리 상태를 복원합니다. aof 로그가 없으면 rdb 파일을 사용하여 복원합니다. Redis는 정기적으로 AOF를 다시 작성하고 AOF 파일 로그 크기를 압축합니다. Redis 4.0 이후에는 bgsave의 전체 양과 aof의 증가분을 통합하는 하이브리드 지속성 기능이 있습니다. 이는 복구 효율성을 보장할 뿐만 아니라 데이터 보안도 고려합니다. bgsave, 포크 및 소 포크의 원칙은 redis가 자식 프로세스를 생성하여 bgsave 작업을 수행한다는 것을 의미하고, cow는 자식 프로세스가 생성된 후 부모 프로세스와 자식 프로세스가 데이터 세그먼트를 공유하고 부모 프로세스가 계속해서 작업을 수행한다는 것을 의미합니다. 읽기 및 쓰기 서비스를 제공하고 더티 페이지를 작성하면 데이터가 점차 하위 프로세스에서 분리됩니다.

5. Redis의 만료 전략은 무엇입니까? LRU 알고리즘을 아시나요? 이를 구현하기 위해 Java 코드를 작성하시겠습니까?

만료 전략:

시간 만료(키 1개, 타이머 1개), 지연 만료: 키를 사용할 때만 키가 만료되었는지 판단하고 만료되면 삭제됩니다. 주기적 만료: 처음 두 가지 사이의 절충안입니다.

LRU: newLinkedHashMap(capacity,DEFAULT_LOAD_FACTORY,true); 세 번째 매개변수는 true로 설정됩니다. 이는 연결 목록이 액세스 순서에 따라 정렬되고 false로 설정된 LRU 캐시로 사용될 수 있음을 의미합니다. 이는 연결 목록이 삽입 순서에 따라 정렬되어 FIFO 캐시로 사용될 수 있음을 의미합니다.

LRU 알고리즘 구현:

은 양방향 연결 목록을 통해 구현되고, 새로운 데이터가 연결 목록의 헤드에 삽입됩니다.
캐시에 도달할 때마다(즉, 캐시된 데이터에 액세스할 때마다) 데이터가 연결 목록의 선두로 이동합니다.
연결 목록이 가득 차면 마지막에 데이터를 삭제합니다. 연결리스트의.

LinkedHashMap: HashMap과 이중 연결 목록의 조합이 LinkedHashMap입니다. HashMap은 순서가 없으며 LinkedHashMap은 추가 이중 연결 목록을 유지하여 반복 순서를 보장합니다. 반복 순서는 삽입 순서(기본값) 또는 액세스 순서일 수 있습니다.

6. 캐시 침투, 캐시 붕괴, 캐시 사태 해결?

** 캐시 침투: ** 존재하지 않아야 하는 데이터를 쿼리하는 것을 의미합니다. 스토리지 계층에서 데이터를 찾을 수 없으면 캐시에 기록되지 않습니다. 쿼리가 요청될 때마다 DB로 전송되어 DB가 중단될 수 있습니다.

해결책:

쿼리에서 반환된 데이터는 비어 있습니다. 이 빈 결과는 여전히 캐시되지만 만료 시간은 더 짧아집니다.
블룸 필터: 가능한 모든 데이터를 하나로 해시합니다. 충분히 크면 존재하지 않아야 하는 데이터가 이 비트맵에 의해 가로채어 DB 쿼리를 방지합니다.

** 캐시 분석: ** 만료 시간이 설정된 키의 경우 캐시가 특정 시점에 만료되면 해당 시점에 이 키에 대한 동시 요청이 많이 발생하게 됩니다. 이러한 요청은 일반적으로 캐시가 만료되었음을 확인하며, 이때 데이터가 백엔드 DB에서 로드되어 캐시로 복원됩니다. 이때 대량의 동시 요청이 즉시 DB를 압도할 수 있습니다.

해결책:

뮤텍스 잠금 사용: 캐시가 실패하면 즉시 Ioaddb로 이동하지 마십시오. 먼저 Redis와 같은 setnx를 사용하여 작업이 성공적으로 반환되면 Ioaddb 작업을 수행하고 설정합니다. 그렇지 않으면 캐시 가져오기 방법을 다시 시도하세요.
만료되지 않음: 물리적은 만료되지 않지만 논리는 만료됩니다(백그라운드 비동기 스레드 새로 고침). Cache Avalanche(캐시 애벌런치): 캐시를 설정할 때 동일한 만료 시간을 사용하여 특정 순간에 캐시가 동시에 만료되도록 하고 모든 요청이 DB로 전달되며 DB가 순간적으로 압력을 받아 애벌런치를 유발합니다. 캐시 분석과의 차이점: 눈사태는 많은 키이고, 분석은 특정 키 캐시입니다.

해결책:

캐시 만료 시간을 분산시키세요. 예를 들어 원래 만료 시간에 임의의 값(예: 1~5분)을 추가하여 각 캐시 만료 시간의 반복률을 줄일 수 있습니다. , 집단적인 실패 이벤트를 발생시키기는 어렵습니다.

7. 캐시를 선택할 때 redis를 선택할 때와 memcached를 선택할 때

redis를 선택할 경우:

복잡한 데이터 구조, 값 데이터는 hash, list, set, ordered set 등입니다. 이 경우 memcache가 이러한 데이터 구조를 충족할 수 없기 때문에 redis가 선택됩니다. 가장 일반적인 사용 시나리오는 사용자 주문 목록, 사용자 메시지, 게시물 댓글 등입니다.
데이터 지속성 기능이 필요하지만 Redis가 중단되면 메모리가 즉시 데이터베이스에 부담을 주지 않고 핫 데이터를 빠르게 복원할 수 있습니다. 읽기 전용 및 데이터 일관성 요구 사항이 높지 않은 시나리오의 경우
고가용성을 위해 영구 스토리지를 사용할 수 있습니다. Redis는 클러스터를 지원하며 Memcache의 경우 고가용성을 달성하려는 경우 활성 복제 및 읽기-쓰기 분리를 달성할 수 있습니다. , 보조 개발을 수행해야 합니다.
저장되는 콘텐츠는 상대적으로 크며, Memcache에 저장되는 최대값은 1M입니다.

memcache 선택 시나리오:

Pure KV, 매우 많은 양의 데이터가 있는 비즈니스의 경우 Memcache는 다음과 같은 이유로 더 적합합니다.

Memcache의 메모리 할당은 사전 할당된 메모리 풀 관리 방식을 채택하므로 메모리 할당 시간을 절약할 수 있습니다. Redis는 임시 애플리케이션 공간이므로 조각화가 발생할 수 있습니다.
Memcache는 가상 메모리를 사용하여 모든 데이터를 물리적 메모리에 저장합니다. Redis에는 이론적으로 물리적 메모리보다 더 많은 데이터를 저장할 수 있는 자체 VM 메커니즘이 있습니다. 이 시점부터 데이터 양이 많으면 memcache가 더 빠릅니다
Memcache는 Non-Blocking 10 재사용 모델을 사용하고 Redis도 Non-Blocking I을 사용합니다. 모델을 재사용하지만 Redis는 KV 스토리지 이외의 일부 정렬, 집계 기능 및 복잡한 CPU 계산도 제공하므로 전체 I0 스케줄링을 차단합니다. 이러한 관점에서 Redis는 더 많은 기능을 제공하므로 Memcache가 더 빠릅니다
스레딩 모델의 경우 Memcache는 멀티스레딩을 사용하고 기본 스레드는 수신 대기하며 작업자 하위 스레드는 요청을 수락하고 읽기 및 쓰기를 수행합니다. 이 프로세스에서 잠금 충돌이 발생할 수 있습니다. Redis에서 사용하는 단일 스레드는 잠금 충돌이 없지만 처리량을 향상시키기 위해 멀티 코어의 특성을 사용하기 어렵습니다.

8. 캐시가 데이터베이스와 일치하지 않으면 어떻게 해야 하나요?

메인 메모리를 분리하고 읽기-쓰기 분리 데이터베이스를 채택한다고 가정해 보겠습니다.
스레드 A가 먼저 캐시된 데이터를 삭제한 후 해당 데이터를 메인 라이브러리에 쓰면 이때 메인 라이브러리 간의 동기화가 이루어집니다. 스레드 B가 캐시에서 데이터를 읽는 데 실패하면 슬레이브 라이브러리에서 이전 데이터를 읽은 다음 캐시에 업데이트합니다.

위 불일치가 발생하는 이유는 마스터-슬레이브 데이터베이스 데이터가 일치하지 않기 때문입니다. 캐시를 추가한 후 마스터-슬레이브 불일치 시간이 길어집니다.

처리 아이디어: 슬레이브 데이터베이스에서 데이터가 업데이트되면 캐시에 있는 데이터도 동시에 업데이트됩니다. 즉, 슬레이브 데이터베이스에서 데이터가 업데이트되면 삭제 메시지가 캐시로 전송됩니다. 이 기간 동안 기록된 오래된 데이터를 제거합니다.

9. 마스터 데이터베이스와 슬레이브 데이터베이스 간의 불일치를 해결하는 방법은 무엇입니까?

시나리오 설명: 마스터-슬레이브 라이브러리의 경우 읽기와 쓰기가 분리됩니다. 마스터-슬레이브 라이브러리 업데이트 동기화에 시간 차이가 있으면 마스터-슬레이브 라이브러리 데이터에 불일치가 발생합니다.

이 데이터 불일치를 무시하세요. 데이터 일관성 요구 사항이 높지 않으면 비즈니스 조건에서는 실시간 일관성이 필요하지 않을 수 있습니다.

메인 라이브러리를 강제로 읽습니다. 데이터베이스를 읽고 씁니다. 기본 라이브러리에 캐시를 추가하여 데이터 읽기 성능을 향상시킵니다.
메인 라이브러리를 선택적으로 읽고, 메인 라이브러리에서 읽어야 할 데이터를 기록하기 위해 캐시를 추가하고, 어떤 라이브러리, 어떤 테이블, 어떤 기본 키를 캐시 키로 사용하고, 캐시 만료 시간을 설정하여 동기화하는지 마스터 및 슬레이브 라이브러리 시간, 캐시에 이 데이터가 있으면 메인 라이브러리에서 직접 읽습니다. 캐시에 이러한 기본 키가 없으면 해당 슬레이브 라이브러리에서 읽습니다.

마스터는 RDB 메모리 스냅샷 및 AOF 로그 파일과 같은 지속성 작업을 수행하지 않는 것이 가장 좋습니다.

데이터가 중요한 경우 슬레이브는 AOF 백업을 활성화하면 초당 한 번씩 동기화하도록 정책이 설정됩니다
마스터-슬레이브 복제 속도와 연결 안정성을 위해서는 마스터와 슬레이브가 LAN에 있는 것이 가장 좋습니다
스트레스를 받는 마스터 라이브러리에 슬레이브 라이브러리를 추가하지 마세요.
마스터-슬레이브 복제에 메시 구조를 사용하지 말고 선형 구조, Master<–Slave1<-Slave2…

voltile-lru가 설정되었습니다. 만료 시간 데이터 세트에서 가장 최근에 사용된 데이터를 선택하여 제거합니다.

voltile-ttl은 데이터베이스 세트에서 만료될 데이터를 선택합니다. 만료 시간이 설정된 데이터 세트

voltile-random은 만료 시간이 설정된 데이터 세트에서 제거할 데이터를 선택합니다

allkeys-lru는 제거할 데이터 세트에서 가장 최근에 사용된 데이터를 선택합니다

allkeys-random은 데이터 세트에서 제거할 데이터

no-eviction은 데이터 제거를 금지합니다

12. Redis에는 어떤 데이터 구조가 있습니까

String String, Dictionary Hash, list, set, Ordered Set SortedSet. 고급 사용자라면 더 많은 것이 있을 것입니다. 중급 또는 고급 Redis 사용자라면 다음과 같은 데이터 구조 HyperLogLog, Geo 및 Pub/Sub도 추가해야 합니다.

13. Redis에 1억 개의 키가 있고 그 중 100,000개가 고정된 알려진 접두사로 시작한다고 가정합니다.

key 명령을 사용하여 지정된 패턴의 키 목록을 검색하세요.

그러자 상대방은 이렇게 물었습니다. 이 Redis가 온라인 비즈니스에 서비스를 제공하고 있다면, 키 명령을 사용할 때 어떤 문제가 있나요?

이제 Redis의 핵심 기능인 Redis의 단일 스레딩에 답해야 합니다. 키 명령으로 인해 스레드가 일정 시간 동안 차단되고 명령이 실행될 때까지 온라인 서비스가 일시 중지됩니다. 이때, scan 명령을 사용하면 차단 없이 지정된 모드의 키 목록을 추출할 수 있지만 클라이언트에서 한 번만 수행하면 특정 중복 가능성이 있지만 전체 시간이 소요됩니다. 직접 사용하는 것보다 길어집니다.

14. Redis를 사용하여 비동기 대기열을 수행한 적이 있습니까? 목록 유형을 사용하여 데이터 정보를 저장하고, lpop이 메시지를 소비하면 일정 시간 동안 잠을 잘 수 있습니다. , 그런 다음 정보가 있는지 확인하십시오. 정보가 없으면 잠을 자고 싶지 않으면 정보가 도착할 때까지 blpop을 사용할 수 있습니다. Redis는 게시/구독 주제 구독 모델을 통해 하나의 생산자와 여러 소비자를 구현할 수 있습니다. 물론 소비자가 오프라인 상태가 되면 생성된 메시지가 손실됩니다.

15. Redis는 지연 대기열을 어떻게 구현합니까?

sortedset를 사용하고, 타임스탬프를 점수로 사용하고, 메시지 내용을 키로 사용하고, zadd를 호출하여 메시지를 생성하고, 소비자는 zrangbyscore를 사용하여 폴링 처리를 위해 n초 전의 데이터를 얻습니다.

16. Redis란 무엇인가요? 장점과 단점을 간략하게 설명해주세요.

Redis는 기본적으로 memcached와 마찬가지로 Key-Value 유형의 인메모리 데이터베이스입니다. 전체 데이터베이스는 작업을 위해 메모리에 로드되고, 데이터베이스 데이터는 정기적으로 비동기 작업을 통해 하드 디스크에 플러시되어 저장됩니다. .

순수한 메모리 작업이기 때문에 Redis의 성능은 매우 좋으며 초당 100,000회 이상의 읽기 및 쓰기 작업을 처리할 수 있으며 수행하는 것으로 알려진 Key-ValueDB 중 가장 빠릅니다.

Redis의 우수성은 성능만이 아닙니다. Redis의 가장 큰 매력은 다양한 데이터 구조 저장을 지원한다는 것입니다. 또한, 1MB의 데이터만 저장할 수 있는 memcached와 달리 단일 값의 최대 한도는 1GB입니다. 따라서 Redis를 사용하여 많은 유용한 기능을 얻을 수 있습니다.

예를 들어 그의 List를 사용하여 FIFO 이중 연결 목록을 만들어 가벼운 고성능 메시지 대기열 서비스를 구현하고 Set을 사용하여 고성능 태그 시스템 등을 만듭니다.

또한 Redis는 저장된 Key-Value의 만료 시간을 설정할 수도 있으므로 Memcached의 향상된 버전으로도 사용할 수 있습니다. Redis의 가장 큰 단점은 데이터베이스 용량이 물리적 메모리에 의해 제한되어 대용량 데이터의 고성능 읽기 및 쓰기에 사용할 수 없다는 것입니다. 따라서 Redis에 적합한 시나리오는 주로 고성능 작업 및 적은 양의 계산으로 제한됩니다. 데이터.

17. Memcached에 비해 Redis의 장점은 무엇인가요?

memcached의 모든 값은 간단한 문자열입니다. 이를 대체하기 위해 redis는 더 풍부한 데이터 유형을 지원합니다

Redis는 memcached보다 훨씬 빠릅니다
redis는 데이터를 유지할 수 있습니다
18. Redis는 어떤 데이터 유형을 지원합니까?

String, List, Set, SortedSet, hashes

19. Redis는 주로 어떤 물리적 리소스를 소비하나요?

메모리.

20. Redis의 정식 이름은 무엇인가요?

원격 사전 서버

21. Redis에는 어떤 데이터 제거 전략이 있나요?

noeviction: 메모리 제한에 도달하고 클라이언트가 더 많은 메모리를 사용하게 하는 명령을 실행하려고 하면 오류를 반환합니다(대부분의 쓰기 명령이지만 DEL 및 몇 가지 예외). allkeys-lru: 다음을 시도합니다. 새로 추가된 데이터에 저장할 공간이 있도록 최소 사용 키(LRU)를 재활용합니다.

휘발성-lru: LRU(최소 사용 키)를 재활용하려고 시도하지만 만료된 세트의 키만 사용하여 새로 추가된 데이터를 저장할 공간을 확보합니다.

allkeys-random: 무작위 키를 재활용하여 새로 추가된 데이터를 위한 공간을 만듭니다.

휘발성-랜덤: 새로 추가된 데이터에 저장할 공간이 있도록 무작위 키를 재활용합니다. 단, 만료된 세트의 키에 대해서만 가능합니다.

휘발성-ttl: 만료된 세트의 키를 재활용하고 수명(TTL)이 더 짧은 키에 우선순위를 부여하여 새로 추가된 데이터를 저장할 공간을 확보합니다.

22. Redis는 왜 Windows 버전을 공식적으로 제공하지 않나요?

현재 Linux 버전은 상당히 안정적이고 사용자 수가 많기 때문에 호환성 및 기타 문제가 발생할 수 있는 Windows 버전을 개발할 필요가 없습니다.

23. 문자열 유형 값을 저장할 수 있는 최대 용량은 얼마인가요?

512M

24. Redis는 왜 모든 데이터를 메모리에 저장해야 하나요?

가장 빠른 읽기 및 쓰기 속도를 달성하기 위해 Redis는 모든 데이터를 메모리로 읽고 데이터를 디스크에 비동기식으로 씁니다. 그래서 redis는 빠른 속도와 데이터 지속성의 특징을 가지고 있습니다. 데이터가 메모리에 저장되지 않으면 디스크 I/O 속도가 Redis 성능에 심각한 영향을 미칩니다.

오늘날 메모리가 점점 저렴해짐에 따라 redis는 점점 더 인기를 끌 것입니다. 사용되는 최대 메모리가 설정되면 기존 데이터 레코드 수가 메모리 제한에 도달한 후에는 새 값을 삽입할 수 없습니다.

25. Redis 클러스터 솔루션을 어떻게 구현해야 합니까? 계획은 무엇입니까?

코디스.

현재 가장 일반적으로 사용되는 클러스터 솔루션은 기본적으로 twemproxy와 동일한 효과를 가지지만, 노드 수가 변경되면 오래된 노드 데이터를 새로운 해시 노드로 복구하는 기능을 지원합니다.

rediscluster3.0에 포함된 클러스터는 일관된 해싱이 아닌 분산 알고리즘이 아닌 해시 슬롯 개념과 자체적으로 노드 설정 슬레이브 노드를 지원하는 것이 특징입니다. 자세한 내용은 공식 문서를 참조하세요.
비즈니스 코드 계층에서 구현되면 관련되지 않은 여러 Redis 인스턴스가 생성됩니다. 코드 계층에서는 키에 대해 해시 계산이 수행된 다음 해당 Redis 인스턴스가 데이터를 작동하는 데 사용됩니다. 이 방법은 해시 계층 코드에 대한 요구 사항이 상대적으로 높습니다. 고려 사항에는 노드 오류 후 대체 알고리즘 솔루션, 데이터 충격 후 자동 스크립트 복구, 인스턴스 모니터링 등이 포함됩니다.

26. Redis 클러스터 솔루션으로 인해 전체 클러스터를 사용할 수 없게 되는 상황은 무엇입니까?

복제 모델이 없는 세 개의 노드 A, B, C가 있는 클러스터에서 노드 B에 장애가 발생하면 전체 클러스터는 5501~11000 범위의 슬롯이 부족하여 사용할 수 없다고 생각하게 됩니다.

27. MySQL에는 2천만 개의 데이터가 있지만 Redis에는 20만 개의 데이터만 저장됩니다. Redis의 데이터가 핫 데이터인지 확인하는 방법은 무엇입니까?

Redis 메모리 데이터 세트의 크기가 특정 크기로 증가하면 데이터 제거 전략이 구현됩니다.

28. Redis에 적합한 시나리오는 무엇입니까?

세션 캐시
Redis 사용에 가장 일반적으로 사용되는 시나리오 중 하나는 세션 캐시입니다. Redis를 사용하여 다른 스토리지(예: Memcached)보다 세션을 캐시할 때의 이점은 Redis가 지속성을 제공한다는 것입니다. 엄격하게 일관성을 요구하지 않는 캐시를 유지 관리할 때 대부분의 사람들은 사용자의 장바구니 정보가 모두 손실되면 불만을 품게 됩니다. 그래도 여전히 그럴까요?

다행히 Redis가 수년에 걸쳐 개선됨에 따라 Redis를 올바르게 사용하여 세션 문서를 캐시하는 방법을 쉽게 찾을 수 있습니다. 잘 알려진 상용 플랫폼인 Magento도 Redis 플러그인을 제공합니다.
전체 페이지 캐시(FPC)
Redis는 기본 세션 토큰 외에도 매우 간단한 FPC 플랫폼도 제공합니다. 일관성 문제로 돌아가서, Redis 인스턴스가 다시 시작되더라도 사용자는 디스크 지속성으로 인해 페이지 로딩 속도가 떨어지는 것을 볼 수 없습니다. 이는 PHP 로컬 FPC와 유사하게 크게 개선되었습니다.
Magento를 다시 예로 들면, Magento는 Redis를 전체 페이지 캐시 백엔드로 사용할 수 있는 플러그인을 제공합니다.
또한 WordPress 사용자를 위해 Pantheon에는 매우 유용한 플러그인 wp-redis가 있어 탐색한 페이지를 최대한 빨리 로드하는 데 도움이 됩니다.
Queue
메모리 저장 엔진 분야에서 Reids의 가장 큰 장점 중 하나는 Redis를 좋은 메시지 큐 플랫폼으로 사용할 수 있도록 하는 목록 및 집합 작업을 제공한다는 것입니다. Redis가 대기열로 사용하는 작업은 목록에서 로컬 프로그래밍 언어(예: Python)의 푸시/팝 작업과 유사합니다.
Google에서 "Redisqueues"를 빠르게 검색하면 수많은 오픈 소스 프로젝트를 즉시 찾을 수 있습니다. 이러한 프로젝트의 목적은 Redis를 사용하여 다양한 대기열 요구 사항을 충족하는 매우 좋은 백엔드 도구를 만드는 것입니다. 예를 들어 Celery에는 Redis를 브로커로 사용하는 백엔드가 있습니다. 여기에서 볼 수 있습니다.
Leaderboard/Counter
Redis는 메모리에서 숫자를 늘리거나 줄이는 연산을 매우 잘 구현합니다. 세트(Sets)와 정렬된 세트(SortedSet)도 이러한 작업을 수행하는 것을 매우 간단하게 해줍니다. Redis는 이 두 가지 데이터 구조를 제공합니다. 따라서 우리는 정렬된 세트에서 상위 10명의 사용자를 가져오고 싶습니다. 이를 "user_scores"라고 부르겠습니다. 다음과 같이 하면 됩니다.
물론 이것은 사용자 점수가 정렬된 것을 기반으로 한다고 가정합니다. 오름차순으로. 사용자와 사용자의 점수를 반환하려면 다음과 같이 실행해야 합니다.
ZRANGEuser_scores010WITHSCORES
AgoraGames는 Ruby로 구현된 좋은 예이며 리더보드는 Redis를 사용하여 데이터를 저장합니다. 여기서 볼 수 있습니다.
Publish/Subscribe
마지막(그러나 가장 중요한 것은) Redis의 게시/구독 기능입니다. 게시/구독에는 실제로 많은 사용 사례가 있습니다. 사람들이 이를 소셜 네트워크 연결에서 게시/구독 기반 스크립트의 트리거로 사용하고 심지어 Redis의 게시/구독 기능을 사용하여 채팅 시스템을 구축하는 것을 보았습니다!

29. Redis에서 지원하는 Java 클라이언트는 무엇입니까? 공식적으로 권장되는 것은 무엇입니까?

Redisson, Jedis, 양상추 등 공식적인 권장 사항은 Redisson을 사용하는 것입니다.

30. Redis와 Redisson은 어떤 관계인가요?

Redisson은 사용자가 분산 환경에서 일부 Java 객체(Bloomfilter, BitSet, Set, SetMultimap, ScoredSortedSet, SortedSet, Map, ConcurrentMap, List, ListMultimap 등)를 쉽게 구현할 수 있도록 도와주는 고급 분산 조정 Redis 클라이언트입니다. , BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, ReadWriteLock, AtomicLong, CountDownLatch, 게시/구독, HyperLogLog).

31. 제디스와 레디슨의 장점과 단점은 무엇인가요?

Jedis는 Redis에 의해 Java로 구현된 클라이언트입니다. 해당 API는 Redis 명령에 대해 상대적으로 포괄적인 지원을 제공합니다.
Redisson은 Jedis에 비해 분산되고 확장 가능한 Java 데이터 구조를 구현하며 문자열 작업을 지원하지 않습니다. 정렬, 트랜잭션, 파이프라인, 파티션과 같은 Redis 기능을 지원합니다. Redisson의 목적은 Redis에서 사용자의 우려사항을 분리하여 사용자가 비즈니스 로직 처리에 더 집중할 수 있도록 하는 것입니다.

32. Redis에서 비밀번호를 설정하고 확인하는 방법은 무엇인가요?

비밀번호 설정: config set require pass 123456 인증 비밀번호: auth123456

33. Redis 해시 슬롯의 개념에 대해 이야기해 주세요.

Redis 클러스터는 일관된 해싱을 사용하지 않지만 해시 슬롯 개념을 도입합니다. Redis 클러스터에는 16384개의 해시 슬롯이 있습니다. 각 키가 CRC16 검사를 통과한 후 모듈로 16384를 사용하여 클러스터의 각 노드를 담당합니다. 해시 슬롯의 일부에 대해.

34. Redis 클러스터의 마스터-슬레이브 복제 모델은 무엇입니까?

일부 노드가 실패하거나 대부분의 노드가 통신할 수 없는 경우에도 클러스터를 계속 사용할 수 있도록 하기 위해 클러스터는 마스터-슬레이브 복제 모델을 사용하며 각 노드에는 N-1 복제본이 있습니다.

35. 운영이 손실되나요? 왜?

Redis는 데이터의 강력한 일관성을 보장하지 않습니다. 즉, 실제로 특정 조건에서는 클러스터의 쓰기 작업이 손실될 수 있습니다.

36. Redis 클러스터는 어떻게 복제되나요?

비동기 복제

37. Redis 클러스터의 최대 노드 수는 몇 개입니까?

16384.

38. Redis 클러스터용 데이터베이스를 선택하는 방법은 무엇입니까?

Redis 클러스터는 현재 데이터베이스를 선택할 수 없으며 기본값은 데이터베이스 0입니다.

39. Redis의 연결성을 테스트하는 방법은 무엇입니까?

ping

40. Redis에서 파이프라인의 용도는 무엇인가요?

요청/응답 서버는 이전 요청이 아직 응답되지 않은 경우에도 새 요청을 처리할 수 있습니다. 이를 통해 응답을 기다리지 않고 서버에 여러 명령을 보내고 마지막으로 한 단계로 해당 응답을 읽을 수 있습니다.

이것은 수십년 동안 널리 사용되어 온 기술인 파이프라이닝입니다. 예를 들어, 많은 POP3 프로토콜은 이 기능에 대한 지원을 구현하여 서버에서 새 이메일을 다운로드하는 프로세스 속도를 크게 향상시킵니다.

41. Redis 트랜잭션을 이해하는 방법은 무엇입니까?

트랜잭션은 단일 격리된 작업입니다. 트랜잭션의 모든 명령은 직렬화되어 순서대로 실행됩니다. 트랜잭션이 실행되는 동안 다른 클라이언트가 보낸 명령 요청으로 인해 중단되지 않습니다. 트랜잭션은 원자성 작업입니다. 즉, 트랜잭션의 모든 명령이 실행되거나 어느 것도 실행되지 않습니다.

42. Redis 트랜잭션과 관련된 명령은 무엇입니까?

MULTI, EXEC, DISCARD, WATCH

43. Rediskey의 만료 시간과 영구 유효성을 각각 설정하는 방법은 무엇입니까?

EXPIRE 및 PERSIST 명령.

44. Redis는 메모리를 어떻게 최적화하나요?

가능한 한 해시를 사용하세요. 해시 테이블(즉, 해시 테이블에 저장되는 숫자가 작음)은 매우 작은 메모리를 사용하므로 데이터 모델을 최대한 해시 테이블로 추상화해야 합니다. 예를 들어 웹 시스템에 사용자 개체가 있는 경우 사용자의 이름, 성, 이메일 및 비밀번호에 대해 별도의 키를 설정하지 말고 모든 사용자 정보를 해시 테이블에 저장하세요.