이 기사에서는 Redis에 대한 인터뷰에서 자주 묻는 몇 가지 질문을 요약하여 면접관이 Redis 주제에 대해 단계별로 심층적으로 진행하는 방법을 시뮬레이션하고 후보자의 Redis 숙달도를 종합적으로 검토하기를 바랍니다. 모두가 도움이 됩니다.
추천 연구: "2022 최신 Redis 인터뷰 질문 및 답변"
Redis는 작성된 한 인터뷰에서 우회할 수 없는 임계값입니다. 이력서에 Redis를 사용해보신 분들이라면 절대 빠져나오실 수 없을 것입니다.
샤오 장:
안녕하세요, 면접관님. 저는 인터뷰를 하러 왔습니다.
인터뷰어:
안녕하세요, Xiao Zhang. 귀하의 이력서를 읽었으며 Redis에 능숙하므로 Redis 관련 몇 가지 질문만 드리겠습니다. 우선 제 질문은 Redis는 단일 스레드인가요, 아니면 멀티 스레드인가요?입니다.
Xiao Zhang:
Redis 버전마다 사용되는 스레딩 모델이 다릅니다. Redis 버전 4.0 이전에는 단일 스레드 모델이 사용되었고, 버전 4.0 이후에는 멀티 스레딩 지원이 추가되었습니다.
4.0 이전에는 Redis가 단일 스레드라고 말했지만 이는 네트워크 I/O 스레드와 Set 및 Get 작업이 하나의 스레드로 완료되었음을 의미했을 뿐입니다. 그러나 Redis 지속성 및 클러스터 동기화는 여전히 다른 스레드를 사용하여 완료됩니다.
멀티 스레딩 지원은 4.0 이후에 추가되었는데 주로 unlink key
、flushdb async
、flushall async
등 빅데이터의 비동기 삭제 기능에 반영되었습니다.
인터뷰어:
답변이 매우 좋습니다. 그럼 Redis는 이전에 왜 싱글 스레드를 사용하기로 결정했나요? 4.0? 그리고 단일 스레드를 사용하면 그렇게 빠른가요?
Xiao Zhang:
개인적으로 단일 스레드를 선택하는 이유는 사용이 간편하고, 잠금 경쟁이 없으며, 모든 작업이 잠금 없이 완료될 수 있고, 교착 상태로 인한 성능 및 시간 오버헤드가 없기 때문이라고 생각합니다. 그러나 동시에 단일 스레드는 멀티 코어 CPU의 성능을 완전히 발휘할 수 없습니다.
싱글 스레드가 이렇게 빠른 이유는 주로 다음과 같은 이유가 있다고 생각합니다.
Redis의 대부분의 작업은 메모리에서 완료되며 메모리 자체의 실행 효율성이 매우 빠르며 효율적인 데이터 구조를 사용합니다. 해시 테이블, 스킵 테이블 등이 있습니다.
단일 스레드를 사용하면 다중 스레드 경쟁을 피하고 다중 스레드 전환으로 인한 시간 및 성능 오버헤드를 절약하며 교착 상태가 발생하지 않습니다.
I/O 멀티플렉싱 메커니즘을 사용하여 다수의 클라이언트 소켓 요청을 처리합니다. 이는 Redis가 네트워크 통신과 I/O 읽기 및 쓰기 프로세스를 효율적으로 수행할 수 있는 비차단 I/O 모델을 기반으로 하기 때문입니다. 더 이상 차단하지 마세요.
인터뷰어:
좋아요, Redis는 어떻게 데이터 손실을 방지하나요?
Xiao Zhang:
Redis 데이터는 메모리에 저장됩니다. Redis 데이터가 손실되지 않도록 하려면 데이터를 메모리에서 디스크로 저장해야 디스크에서 원본 데이터를 복원할 수 있습니다. 서버가 다시 시작된 후 이는 Redis의 데이터 지속성입니다. Redis 데이터를 유지하는 방법에는 세 가지가 있습니다.
AOF 로그(Append Only File): 모든 작업 명령을 기록하고 텍스트 형식으로 파일에 추가합니다.
RDB 스냅샷(Redis DataBase): 특정 순간의 메모리 데이터를 바이너리 형식으로 디스크에 씁니다.
하이브리드 지속성 방법: Redis 4.0에는 RDB와 AOF의 장점을 통합한 새로운 하이브리드 지속성 방법이 추가되었습니다.
인터뷰어:
그럼 각각 AOF와 RDB의 구현 원칙에 대해 이야기해주세요.
Xiao Zhang:
AOF는 쓰기 후 로깅을 사용합니다. Redis는 먼저 명령을 실행하여 메모리에 데이터를 쓴 다음 로그를 파일에 기록합니다. AOF 로그에는 실제 데이터가 아닌 동작 명령이 기록되는데, AOF 방식을 사용하여 오류 복구를 수행하는 경우에는 전체 로그를 실행해야 합니다.
RDB는 작업이 아닌 특정 시점의 데이터를 기록하는 방식을 사용합니다. 따라서 오류 복구를 위해 RDB 방식을 사용할 경우 빠른 복구를 위해 RDB 파일을 메모리로 직접 읽어들이기만 하면 됩니다. .
인터뷰어:
방금 AOF가 "쓰기 후 로그" 방법을 사용한다고 말씀하셨는데, 우리가 일반적으로 사용하는 MySQL은 "사전 쓰기 로그" 방법을 사용합니다. 그럼 왜 Redis는 명령을 먼저 실행한 다음 실행해야 할까요? 데이터를 기록하는 것은 어떻습니까?
Xiao Zhang: 이마에 땀이 나기 시작했어요. 어떤 질문을 하시나요? . .
글쎄, 이는 주로 Redis가 로그를 쓰기 전에 명령에 대한 구문 검사를 수행하지 않기 때문에 잘못된 명령이 기록되는 것을 방지하기 위해 성공적으로 실행된 명령만 기록하고 명령이 실행된 후에 로그를 작성해도 현재 쓰기 작업이 차단되지 않기 때문입니다.
인터뷰어:
그럼 이후 일기를 쓰는 데에는 어떤 위험이 있나요?
샤오 장:
나...이걸 어떻게 해야할지 모르겠어요.
인터뷰어:
글쎄요, 로그를 작성할 때 발생할 수 있는 두 가지 주요 위험이 있습니다:
데이터가 손실될 수 있습니다: Redis가 방금 명령 실행을 마쳤고 이때 오류가 발생하면 이 명령이 발생합니다. 분실의 위험이 있습니다.
다른 작업을 차단할 수 있음: AOF 로그는 실제로 메인 스레드에서 실행되므로 Redis가 로그 파일을 디스크에 쓸 때 여전히 후속 작업을 차단하고 실행할 수 없습니다.
또 다른 질문이 있습니다. 스냅샷을 찍을 때 RDB가 스레드를 차단합니까?
Xiao Zhang:
Redis는 RDB 스냅샷 파일을 생성하는 두 가지 명령, 즉 save 및 bgsave를 제공합니다. save 명령은 메인 스레드에서 실행되며 차단을 유발합니다. bgsave 명령은 메인 스레드를 차단하지 않고 RDB 파일을 쓰기 위한 하위 프로세스를 생성합니다. 이는 Redis RDB의 기본 구성이기도 합니다.
인터뷰어:
RDB 스냅샷 촬영 시 데이터를 수정할 수 있나요?
Xiao Zhang:
save는 동기식이며 클라이언트 명령을 차단하지만 bgsave 중에 수정될 수 있습니다.
인터뷰어:
그렇다면 bgsave가 스냅샷을 찍을 때 Redis는 데이터 수정을 허용하는 문제를 어떻게 해결합니까?
Xiao Zhang: (왜 아직도 물어보시나요... 방법을 모르겠어요!)
음, 이건 잘 모르겠어요...
인터뷰어:
여기에서는 주로 bgsave 코드>의 하위 스레드에 의해 구현되며 구체적인 작업은 다음과 같습니다. <code>bgsave
的子线程实现的,具体操作如下:
如果主线程执行读操作,则主线程和 bgsave
子进程互相不影响;
如果主线程执行写操作,则被修改的数据会复制一份副本,然后 bgsave
bgsave
하위 프로세스는 읽기 작업을 수행하지 않습니다. 메인 스레드가 쓰기 작업을 수행하면 수정된 데이터의 복사본이 생성되고 bgsave
하위 프로세스가 복사본 데이터를 RDB에 씁니다. 이 프로세스 중에 메인 스레드는 여전히 원본 데이터를 직접 수정할 수 있습니다.
RDB에서 Redis의 실행 빈도는 매우 중요합니다. 이는 스냅샷 데이터의 무결성과 Redis의 안정성에 영향을 미치기 때문입니다. 따라서 Redis 4.0 이후에는
AOF 및 RDB의 데이터 지속성 메커니즘이 추가되었습니다. 하이브리드가 추가되었습니다
: 데이터를 RDB 형식으로 파일에 쓴 후 후속 작업 명령을 AOF 형식으로 파일에 저장하면 Redis의 재시작 속도를 보장할 뿐만 아니라 데이터 위험도 줄어듭니다. 손실. 샤오 장: 배웠어요, 배웠어요.인터뷰어:
그렇다면 Redis가 어떻게 고가용성을 달성하는지 알려주실 수 있나요?
Xiao Zhang:Redis에서 고가용성을 달성하는 세 가지 주요 방법은 마스터-슬레이브 복제, 센티넬 모드, Redis 클러스터입니다.
마스터-슬레이브 복제
이전 Redis 서버의 데이터를 여러 슬레이브 Redis 서버, 즉 마스터-슬레이브 모델로 동기화합니다. 이는 MySQL 마스터-슬레이브 복제와 동일한 원리입니다.
Sentinel Mode
Redis 마스터-슬레이브 서비스를 사용할 때 문제가 발생합니다. 즉, Redis 마스터-슬레이브 서버에 장애가 발생하여 다운되면 수동으로 복원해야 합니다. 이 문제를 해결하기 위해 Redis는 Sentry 모드를 추가했습니다(Sentinel 모드는 마스터 및 슬레이브 서버를 모니터링하고 자동 재해 복구 기능을 제공할 수 있기 때문입니다).
Redis 클러스터(클러스터)
Redis 클러스터는 Redis 3.0 버전에서 출시된 분산형 운영 모드입니다. 이는 서로 다른 서버에 데이터를 분산시킵니다. 단일 마스터 노드를 사용하여 Redis 서비스의 읽기 및 쓰기 성능을 향상시킵니다.
인터뷰어:
센티넬 모드를 사용하여 데이터의 복사를 보장하고 센티널을 통해 가용성을 모니터링합니다. 마스터가 실패하면 슬레이브 노드가 마스터 노드로 선택됩니다. 예,그래서요. 왜 여전히 클러스터 모드를 사용해야 합니까?
Xiao Zhang: 음, 센티넬 모드는 여전히 마스터-슬레이브 노드입니다. 마스터-슬레이브 모드에서는 슬레이브 노드를 추가하여 읽기 동시성 기능을 확장할 수 있지만 쓰기 기능을 확장할 방법은 없습니다. 저장 능력은 마스터 노드가 가질 수 있는 최대치입니다. 따라서 쓰기 기능과 저장 기능을 확장하려면 클러스터 모드를 도입해야 합니다.인터뷰어:
클러스터에 마스터 노드가 너무 많은데, Redis 클러스터는 저장할 때 어떤 노드를 선택할지 어떻게 결정하나요?
Xiao Zhang: 이것은 일종의 해시 알고리즘을 사용해야 하는데 잘 모르겠습니다. . . 🎜🎜인터뷰어:🎜자, 오늘 인터뷰는 여기까지입니다. 돌아가서 인터뷰 알림을 기다리세요.
Xiao Zhang:
알겠습니다. 면접관님 감사합니다. Redis 클러스터가 노드 선택을 구현하는 방법을 알려주실 수 있나요?
인터뷰어:
Redis 클러스터는 일관된 해싱 알고리즘을 사용하여 노드 선택을 구현합니다. 일관적인 해싱 알고리즘이 무엇인지는 직접 확인해 보세요.
Redis 클러스터는 16384개의 슬롯으로 나뉩니다. 해시 슬롯은 데이터 파티션과 유사합니다. 각 키-값 쌍은 해당 키에 따라 해시 슬롯에 매핑됩니다.
키-값 쌍의 키를 기반으로 CRC16 알고리즘에 따라 16비트 값을 계산합니다.
그런 다음 16비트 값을 모듈로 16384로 사용하여 0~16383 범위의 모듈러스를 얻습니다. 각 모듈러스는 해당 숫자가 있는 해시 슬롯을 나타냅니다.
각 Redis 노드는 슬롯의 일부를 처리합니다. 3개의 마스터 노드 ABC를 추가하면 각 노드가 담당하는 슬롯은 다음과 같습니다.
이런 방식으로 클러스터 노드를 선택하면 다음과 같습니다. 깨달았다.
추천 학습: "Redis 동영상 튜토리얼", "2022 최신 Redis 인터뷰 질문 및 답변"
위 내용은 Redis 인터뷰에서 자주 묻는 12가지 핵심 사항(답변 포함)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!