Redis 스레드 모델의 그래픽 분석

이 글은 스레드 모델과 관련된 이슈를 주로 소개하는 Redis에 대한 관련 지식을 제공합니다. Redis는 단일 스레드에 대해 함께 살펴보겠습니다.

추천 학습: Redis 비디오 튜토리얼

Redis는 단일 스레드이므로 주의해야 합니다.

먼저 클라이언트가 있습니다. 이 클라이언트는 실제로 우리보다 앞서 Redis 서버에 연결하기 위해 Redis 클라이언트와 같은 도구를 사용했습니다.
나중에 Java에 통합하면 해당 클라이언트가 실제로 Java로 제공됩니다.

그런 다음 실제로 Redis 중 하나인 Redis 서버를 갖게 됩니다. 전체 서비스가 시작된 후에는 프로세스가 있습니다.
이번 릴리스에는 실제로 내부적으로 두 가지가 있습니다.

먼저 이전 강의에서 이미 소개한 멀티플렉서가 있습니다. 이는 비차단 모델입니다.
실제로는 일부 이벤트를 할당하는 데 특별히 사용되는 파일 이벤트 할당자가 있습니다.

이에 따라 세 가지 프로세서로 나누어지는데, 각각을 살펴보겠습니다.

먼저 연결 응답 핸들러가 있고 마지막으로 명령 요청 핸들러와 명령 응답 핸들러가 있습니다.

어떻게 이해하나요? 먼저 연결 응답 핸들러를 살펴보겠습니다.

응답 프로세서에 연결할 때 주요 기능 중 하나는 클라이언트와의 링크를 유지하는 것입니다.
Redis 서버 중 하나가 시작되면 실제로 연결 응답기와 함께 읽기 이벤트가 번들로 제공됩니다.
전체 이름은 실제로 AE_readable이라고 합니다. 이를 신호라고 생각하면 이러한 이벤트가 발생하며 이 이벤트는 연결 응답 프로세서와 함께 번들로 제공됩니다.

마지막으로 클라이언트 중 하나가 서버와 연결을 설정하려는 경우 이는 실제로 처음에 명령줄 도구에 redis 클라이언트를 입력했음을 의미하며 Go를 통해 연결해야 합니다. 연결을 설정합니다. 연결을 설정할 때 실제로는 읽기 시간인 읽기 플래그를 보냅니다. 이때 Redis 서버에는 실제로 서버 소켓이 있습니다.

서버 소켓은 실제로 클라이언트 소켓 중 하나에 해당합니다. 이는 네트워크 프로그래밍의 콘텐츠이며 이들 간의 통신은 소켓입니다. read와 같은 이벤트에 접촉한 후 처리를 위해 이를 멀티플렉서에 넘겨줍니다.
처리를 그에게 맡기면 실제로는 논블로킹(Non-Blocking) 상태입니다. 일단 받으면 우리처럼 화살에 집어넣을 것입니다.

여기 이 화살표는 실제로 파이프라인이라고 부를 수도 있고 대기열이라고 부를 수도 있습니다. 여기에 던져지면 이 세계는 실제로 파일 이벤트 디스패처에 도달하게 됩니다. 이 할당자가 읽기 이벤트임을 인식하면 연결 응답 프로세서와 일치합니다. 즉, 처리를 위해 이를 넘겨줍니다.
서로 일치하는 읽기입니다.
이때 실제로 클라이언트와 서버가 연결되었음을 나타낼 수 있습니다. 연결이 설정된 후 읽기 플래그가 사용되면 이 이벤트는 실제로 명령 요청 프로세서로 전달됩니다. 이 명령이 프로세서에 요청한다면 구체적으로 요청, 즉 요청을 처리한다고 생각하면 됩니다. 그러면 명령 응답 프로세서는 응답, 즉 응답으로 이해할 수 있습니다.

그러면 클라이언트 측에서 뭔가를 해야 할 수도 있습니다. 예를 들어 값을 설정해야겠죠? 예를 들어 set name ***와 같이 값을 설정하면 이는 실제로 명령입니다.
이 명령의 경우 월드 유형 중 하나는 실제로 읽기입니다. 그런 다음 서버 소켓을 통해 멀티플렉서로 전달됩니다. 이를 얻은 후 대기열에 넣은 다음 파일 이벤트 디스패처로 전달됩니다.

이 파일 이벤트 할당자를 얻은 후 판단을 내리고 일치하는 이벤트가 읽기 이벤트인지 판단합니다. 이때 읽기 이벤트인 경우 명령 요청 프로세서는 명령을 처리하도록 요청받습니다. 그는 그것을 인식할 것이고, 현재의 것이 세트명**이라는 것을 인식할 것이기 때문에 그는 그 과정을 수행할 것입니다. 그는 사용자가 설정한 콘텐츠를 저장하고 이 키 값을 우리 메모리에 저장하기를 원합니다. 이는 실제로 요청인 명령 요청을 처리하는 것입니다.

처리가 완료되면 서면 식별자인 흰색이 할당됩니다. 여기에 이 ​​로고를 쓰면 실제로 응답으로 사용할 수 있습니다. 요청 중 하나가 실제로 처리된 후 명령 입력을 마친 후에 ok가 표시될 수 있기 때문입니다. 그렇죠? 이것이 괜찮다면 실제로 명령 응답 프로세서 중 하나가 우리에게 다시 작성한 콘텐츠와 동일합니다. 그래서 그는 쓰기에 의해 쓰여진 표시를 사용할 것입니다. 이러한 방식으로 작성된 태그 중 하나가 실제로 명령 응답 프로세서와 함께 번들로 제공됩니다. 쓰기의 경우 전체 이름은 실제로 AE_writable이라는 이벤트 유형입니다.

그렇다면 클라이언트에서 실제로 write-back을 수행해야 합니다. 괜찮습니다. 또는 목록을 쿼리하고 목록의 모든 내용을 표시하려는 경우 실제로 쓰기 저장의 경우입니다. write와 같은 이벤트 유형인 콘텐츠를 콘솔 하단에 표시하려고 합니다. 그런 다음 멀티플렉서로 전달된 다음 파일 이벤트 디스패처 중 하나에 할당된 대기열 중 하나로 전달됩니다. 이번에는 웹 이벤트가 일치합니다. 웹 이벤트가 일치합니다.

이후 명령 응답 프로세서가 다시 쓰기를 수행합니다. 여기에는 OK 또는 획득한 목록의 번호, 목록의 내용 등이 표시됩니다. 표시해야 할 일부 콘텐츠가 있는 한 이는 응답으로 사용됩니다. 즉, 응답 콘텐츠가 클라이언트 중 하나에 다시 기록되어 클라이언트에 표시됩니다. 현재 전체 모델에는 실제로 두 가지 이벤트가 있습니다. 하나는 읽기 가능하고 다른 하나는 쓰기 가능입니다.

물론, 우리가 지금 설정하고 있는 것은 단지 하나의 클라이언트일 뿐입니다. 클라이언트가 여러 명이라면 그들의 원칙은 완전히 동일할 것입니다. 이것은 실제로 릴리스의 스레딩 모델입니다. 처음 접해보면 이해하기 어려울 수도 있지만 상관없습니다. 이 사진은 실제로 모든 사람이 이러한 의도를 심화하는 데 도움이 될 수 있습니다.

그러면 제가 말한 것을 따르면 그의 전체 처리 과정도 이해할 수 있습니다. 모든 분들의 이해를 돕기 위해 여기에 그림을 그려 예시를 들어보겠습니다.

지금 KTV가 있고 이 KTV가 redis라고 가정해 보겠습니다.

그럼 노래하고 싶은 손님이 많을 텐데, 저희 KTV에는 직원이 있을 거예요.
첫 번째 카테고리는 문앞의 접수원이고, 두 번째 카테고리는 로비 매니저입니다.
문 앞에 있는 접수원은 실제로 멀티플렉서이고, 로비 관리자는 실제로 파일 배포자입니다.

그러면 고객은 해당 요청이나 해당 요구 사항이 있어야 합니다. 이때 고객은 문 앞에 있는 접수 담당자에게 간단한 처리를 하도록 해야 합니다.
사용자가 어떤 활동에 참여하고 싶어하는지, 쿠폰이 있는지 등을 알고 싶을 수도 있습니다.

그런 다음 문앞에 있는 주문 받는 사람이 고객이 노래를 부르고 싶어한다고 확신하면 뒤쪽으로 가세요. 뒤에 통로가 있다고 말할 수 있습니다. 이 통로는 실제로 이 통로로 가기 위해 줄을 서는 곳입니다. 안으로 들어가면 KTV 전체의 비즈니스 홀입니다. 비즈니스 홀에는 로비 매니저가 상주해 고객의 실제 요청을 처리해 드립니다.

그러면 우리 KTV 중 하나에는 실제로 상자가 하나씩 있을 것입니다. 각 상자는 사용자를 처리하고 고객의 다양한 요청을 처리합니다. 우리 상자 안에는 사용자의 다양한 요구를 처리할 세 명의 젊은 여성이나 젊은 형제가 있을 것입니다.

예를 들어 첫 번째는 고객을 위해 문을 여는 데 전념합니다. 문을 여는 행위는 고객 중 한 명과 릴리스 사이에 링크를 설정하는 것과 같습니다. 문이 열리면 들어오시면 되겠죠? 그가 들어온 후에는 이 아가씨는 더 이상 그의 해당 업무를 책임지지 않을 것이며, 그는 그를 우리 부하 중 한 명에게 넘겨줄 것입니다. 다음 아가씨나 형제는 사용자를 위해 특별히 몇 가지 요청을 처리할 것입니다.

예를 들어 고객이 노래를 요청하면 노래를 요청한 사람에게 해당 처리를 요청하게 됩니다. 방법은 컴퓨터를 켜고 노래를 주문하고 선택하는 것입니다. 노래를 선택한 후 고객에게 응답해야 합니다. 일리가 있군요, 그렇죠? 고객에게 마이크도 건네줘야 하는데 이때 이런 아가씨가 있다는 알림이 뜨는데, 이 아가씨가 이 마이크를 고객에게 건네줍니다. 지금 가서 노래해 보세요. 우리는 이미 이 노래를 주문했습니다.

이때 고객이 노래를 요청하고 KTV에서 노래를 부르는 모든 행위가 실제로 완료됩니다. 이는 실제로 이전 릴리스 스레드 모델에서 언급한 클라이언트가 수행하는 작업에 해당합니다. 먼저 연결이 설정된 다음 요청이 처리되고 요청 중 하나가 응답됩니다. 총 3단계가 있습니다.

저희 지역에서는 로비 매니저 전체와 그들의 노래 신청 알림이 실제로 내부적으로 처리됩니다. 그것은 우리 상자 중 하나를 기반으로 합니다. 개인실의 경우 Redis에서는 저장, 읽기 등의 작업이 실제로 메모리를 기반으로 하기 때문에 이를 메모리로 사용할 수 있습니다. 그래서 메모리에 있으면 매우 빠릅니다.

개인실에 계시다면 개인실에서 노래 부르기, 과일 주문하기, 맥주 마시기 등을 하실 수 있습니다. 실제로 작업이 모두 내부 상자 중 하나를 기반으로 하는 경우 일련의 작업 등이 실제로 매우 빠르게 완료됩니다.

이것은 실제로 스레드 모델 중 하나에 대한 간단한 이해일 수 있습니다. Redis의 경우 실제로는 단일 스레드 모드입니다. 단일 스레드 모델을 사용하는 것이 왜 매우 빠른가요?

사실 크게 2가지 포인트가 있습니다.
첫 번째 요점은 우리 문 접수원 중 한 명이 실제로 멀티플렉서라는 것입니다. 이 멀티플렉서는 Non-Blocking 모델을 기반으로 하기 때문에 처리 속도가 매우 빠릅니다. 이전 차단 모드로 인해 하나씩 응답을 기다리지 않습니다. 이제 IO 멀티플렉서와 ​​같은 모델이 사용되므로 처리 성능이 실제로 매우 빠릅니다.

다른 부분은 로비 매니저입니다. 이 부분은 실제로 메모리를 기반으로 작동합니다. 순수한 메모리 작업의 경우 실제로는 매우 빠릅니다.

물론 싱글 스레드를 사용한 후 그 기능 중 하나도 언급되었습니다. 싱글 스레드를 사용하면 멀티 스레드를 피할 수 있습니다. 스레드가 여러 개인 경우 해당 컨텍스트 스위치 중 하나를 사용할 수 있기 때문입니다. 일단 전환하면 몇 가지 문제가 발생할 수 있습니다. 또한 일부 해당 손실도 피할 수 있습니다. 따라서 트렁크 모델을 사용하면 동시성과 효율성이 매우 높습니다.

추천 학습: Redis 비디오 튜토리얼

위 내용은 Redis 스레드 모델의 그래픽 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!