Redis의 분산 캐싱에 대한 인터뷰 질문 공유(답변 분석 포함)

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

인터뷰 질문

---

redis와 memcached의 차이점은 무엇인가요? Redis의 스레딩 모델은 무엇입니까? Redis가 단일 스레드로 높은 동시성을 지원할 수 있는 이유는 무엇입니까?

면접자 심리 분석

Redis에 관해 질문할 때 가장 기본적인 질문은 Redis가 실제로는 단일 스레드 작업 모델이라는 점입니다. 이걸 모르면 나중에 Redis를 가지고 놀 때 뭔가 잘못되면 아무것도 모르는 거겠죠?

면접관님이 redis와 memcached의 차이점을 물어보실 수도 있는데, memcached는 초창기에는 주요 인터넷 기업들이 흔히 사용하는 캐싱 솔루션이었지만, 최근에는 기본적으로 redis가 되었고, memcached를 사용하는 기업은 거의 없습니다. [관련 추천 : Redis 영상 튜토리얼]

면접 질문 분석

redis와 memcached의 차이점은 무엇인가요?

redis는 복잡한 데이터 구조를 지원합니다.

memcached에 비해 redis는 더 많은 데이터 구조를 가지며 더 풍부한 데이터 작업을 지원할 수 있습니다. 보다 복잡한 구조와 작업을 지원하기 위해 캐시가 필요한 경우 redis가 좋은 선택이 될 것입니다.

redis는 기본적으로 클러스터 모드를 지원합니다

redis3.

성능 비교

Redis는 단일 코어만 사용하는 반면 memcached는 멀티 코어를 사용할 수 있으므로 각 코어에 작은 데이터를 저장할 때 평균적으로 Redis가 Memcached보다 성능이 더 높습니다. 100,000개가 넘는 데이터의 경우 memcached 성능이 redis보다 높습니다. Redis는 최근 빅데이터 스토리지 성능에 최적화되었지만 여전히 Memcached보다 약간 열등합니다.

redis

redis의 스레딩 모델은 내부적으로 파일 이벤트 핸들러 파일 이벤트 핸들러를 사용합니다. 이 파일 이벤트 핸들러는 단일 스레드이므로 Redis를 단일 스레드 모델이라고 합니다. IO 다중화 메커니즘을 사용하여 동시에 여러 소켓을 수신하고 이벤트를 생성하는 소켓을 메모리 대기열에 푸시합니다. 이벤트 디스패처는 소켓의 이벤트 유형에 따라 처리할 해당 이벤트 프로세서를 선택합니다. file event handler，这个文件事件处理器是单线程的，所以 redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 socket，将产生事件的 socket 压入内存队列中，事件分派器根据 socket 上的事件类型来选择对应的事件处理器进行处理。

文件事件处理器的结构包含 4 个部分：

• 多个 socket
• IO 多路复用程序
• 文件事件分派器
• 事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 socket，会将产生事件的 socket 放入队列中排队，事件分派器每次从队列中取出一个 socket，根据 socket 的事件类型交给对应的事件处理器进行处理。

来看客户端与 redis 的一次通信过程：

要明白，通信是通过 socket 来完成的，不懂的同学可以先去看一看 socket 网络编程。

首先，redis 服务端进程初始化的时候，会将 server socket 的 AE_READABLE 事件与连接应答处理器关联。

客户端 socket01 向 redis 进程的 server socket 请求建立连接，此时 server socket 会产生一个 AE_READABLE 事件，IO 多路复用程序监听到 server socket 产生的事件后，将该 socket 压入队列中。文件事件分派器从队列中获取 socket，交给连接应答处理器。连接应答处理器会创建一个能与客户端通信的 socket01，并将该 socket01 的 AE_READABLE 事件与命令请求处理器关联。

假设此时客户端发送了一个 set key value 请求，此时 redis 中的 socket01 会产生 AE_READABLE 事件，IO 多路复用程序将 socket01 压入队列，此时事件分派器从队列中获取到 socket01 产生的 AE_READABLE 事件，由于前面 socket01 的 AE_READABLE 事件已经与命令请求处理器关联，因此事件分派器将事件交给命令请求处理器来处理。命令请求处理器读取 socket01 的 key value 并在自己内存中完成 key value 的设置。操作完成后，它会将 socket01 的 AE_WRITABLE

파일 이벤트 핸들러의 구조는 4개 부분으로 구성됩니다: 🎜

• 다중 소켓
• IO 멀티플렉서
• 파일 이벤트 디스패처
• 이벤트 프로세서 (연결 응답 프로세서, 명령 요청 프로세서, 명령 응답 프로세서)

🎜여러 소켓은 동시에 서로 다른 작업을 생성할 수 있으며 각 작업은 서로 다른 파일 이벤트에 해당하지만 IO 멀티플렉서는 여러 소켓을 수신하고 이벤트를 생성하는 소켓을 대기열에 넣습니다. 이벤트 디스패처는 매번 대기열에서 소켓을 꺼내어 처리를 위해 소켓 프로세서의 이벤트 유형에 따라 해당 이벤트 처리에 전달합니다. 🎜🎜클라이언트와 Redis 간의 통신 프로세스를 살펴보겠습니다. 🎜🎜🎜🎜통신은 소켓을 통해 완성된다는 점을 이해해야 합니다. 이해하지 못하는 학생은 먼저 소켓 네트워크 프로그래밍을 살펴보세요. 🎜🎜먼저 Redis 서버 프로세스가 초기화되면 서버 소켓의 AE_READABLE 이벤트가 연결 응답 프로세서와 연결됩니다. 🎜🎜클라이언트 소켓01은 연결 설정을 위해 Redis 프로세스의 서버 소켓을 요청합니다. 이때 서버 소켓은 IO 멀티플렉서가 서버 소켓에서 생성된 이벤트를 수신한 후 AE_READABLE 이벤트를 생성합니다. , 대기열에 푸시됩니다. 파일 이벤트 디스패처는 대기열에서 소켓을 가져와 🎜연결 응답 핸들러🎜에 전달합니다. 연결 응답 핸들러는 클라이언트와 통신할 수 있는 소켓01을 생성하고, 소켓01의 AE_READABLE 이벤트를 명령 요청 핸들러와 연결합니다. 🎜🎜이 시점에서 클라이언트가 키 값 설정 요청을 보낸다고 가정합니다. 이때 redis의 소켓01은 AE_READABLE 이벤트를 생성하고 IO 멀티플렉서가 소켓01을 푸시합니다. 대기열, 이때 이벤트 디스패처는 대기열에서 소켓01에 의해 생성된 AE_READABLE 이벤트를 획득합니다. 이벤트 디스패처 처리를 위해 명령 요청 핸들러에 대한 이벤트를 처리합니다. 이 명령은 프로세서에 소켓01의 키 값을 읽고 자체 메모리에서 키 값 설정을 완료하도록 요청합니다. 작업이 완료된 후 소켓01의 AE_WRITABLE 이벤트를 명령 응답 핸들러와 연결합니다. 🎜

클라이언트가 이때 반환 결과를 받을 준비가 되면 redis의 소켓01은 명령 응답 프로세서와 관련된 AE_WRITABLE 事件，同样压入队列中，事件分派器找到相关联的命令回复处理器，由命令回复处理器对 socket01 输入本次操作的一个结果，比如 ok，之后解除 socket01 的 AE_WRITABLE 이벤트를 생성합니다.

이것으로 커뮤니케이션이 완료됩니다. Redis의 커뮤니케이션 과정에 대해서는 체계적인 학습을 위해 "Redis 설계 및 구현 - Huang Jianhong"을 읽어보시길 권장합니다.

redis 단일 스레드 모델이 왜 그렇게 효율적인가요?

• 순수한 메모리 작동.
• 코어는 비차단 IO 다중화 메커니즘을 기반으로 합니다.
• C 언어 구현. 일반적으로 C 언어로 구현된 프로그램은 운영 체제에 "더 가깝고" 상대적으로 더 빠르게 실행됩니다.
• 단일 스레드는 다중 스레드의 빈번한 컨텍스트 전환 문제를 방지하고 다중 스레드로 인해 발생할 수 있는 경쟁 문제를 방지합니다.

인터뷰 질문

---

edis의 동시성 경합 문제는 무엇인가요? 이 문제를 해결하는 방법? Redis 트랜잭션을 위한 CAS 솔루션을 알고 계시나요?

면접관 심리 분석

이것도 온라인에서 매우 흔히 발생하는 문제입니다. 즉, 여러 클라이언트가 동시에 키를 작성먼저 도착해야 할 데이터가 나중에 도착하여 결과가 발생할 수 있습니다. 잘못된 데이터 버전. 또는 여러 클라이언트가 동시에 키를 얻고 값을 수정한 다음 다시 작성하면 데이터가 잘못됩니다.

그리고 redis 자체에는 이 문제를 자연스럽게 해결하는 CAS와 같은 낙관적 잠금 솔루션이 있습니다.

면접 질문 분석

특정 순간 여러 시스템 인스턴스가 특정 키를 업데이트합니다. Zookeeper를 기반으로 분산 잠금을 구현할 수 있습니다. 각 시스템은 사육사를 통해 분산 잠금을 획득하여 하나의 시스템 인스턴스만 동시에 특정 키를 작동할 수 있고 다른 사람은 읽거나 쓸 수 없도록 보장합니다.

캐시에 쓰려는 데이터는 모두 mysql에서 체크아웃되어 mysql에 써져야 한다. mysql에서 체크아웃할 때 타임스탬프를 저장해야 한다. 밖으로도.

쓰기를 원할 때마다 먼저 현재 값의 타임스탬프가 캐시에 있는 값의 타임스탬프보다 최신인지 확인하세요. 그렇다면 쓸 수 있습니다. 그렇지 않으면 새 데이터를 이전 데이터로 덮어쓸 수 없습니다.

더 많은 프로그래밍 관련 지식을 보려면

프로그래밍 비디오를 방문하세요! !

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