이 문서에서는 Redis의 스레드 IO 모델을 빠르게 이해하는 데 도움이 됩니다.

Redis는 단일 스레드인데 왜 그렇게 빠른가요? 한 가지 이유는 redis가 비차단 IO 및 멀티플렉싱을 사용하여 많은 수의 클라이언트 연결을 처리하기 때문입니다. 다음 문서에서는 Redis의 스레드 IO 모델을 이해하는 데 도움이 되기를 바랍니다.

Redis는 단일 스레드 애플리케이션입니다. NodeJ와 Nginx는 모두 단일 스레드입니다. [관련 권장사항: Redis 동영상 튜토리얼]

Redis가 단일 스레드이고 매우 빠른 이유:

첫째, 모든 데이터가 메모리에 있고 모든 작업이 메모리 수준 작업이기 때문에 Redis를 사용할 때. , 시간 복잡도가 O(n)인 명령어에 주의해야 합니다. 데이터 양이 너무 많으면 다른 명령어가 차단되고 대기하게 됩니다.

두 번째 이유는 redis가 사용하기 때문입니다. 비차단 IO 및 멀티플렉싱은 많은 수의 클라이언트 연결을 처리합니다.

Non-blocking IO

소켓의 읽기 및 쓰기 메서드를 사용할 때 기본값은 차단입니다.

즉, 읽기 메서드가 호출되어 매개변수 n을 전달하는데, 이는 읽은 후 반환된다는 의미입니다. 바이트가 None인 경우 스레드는 데이터가 들어오거나 연결이 닫힐 때까지 읽기 메서드에서 계속 대기하며 스레드는 일반적으로 다음 논리를 실행할 수 있습니다. 커널이 소켓이 아니면 차단하지 않습니다. 할당된 쓰기 버퍼가 가득 차면 쓰기 메서드는 버퍼에 여유 공간이 있을 때까지 차단됩니다.

아래 그림은 소켓을 읽고 쓰는 자세한 과정을 보여줍니다.

Non-blocking IO는 소켓을 사용할 때 Non_Blocking 옵션을 제공합니다. 이 옵션이 켜져 있으면 읽기 및 쓰기 메서드는 차단되지 않지만 가능한 한 많이 읽고 쓸 수 있습니다.

읽을 수 있는 양은 커널이 소켓에 할당한 읽기 버퍼의 데이터 바이트 수에 따라 다릅니다. 쓸 수 있는 양은 소켓의 쓰기 버퍼에 커널이 할당한 데이터 바이트 수에 따라 다릅니다.

읽기 및 쓰기 메서드는 반환 값을 통해 프로그램에서 읽고 쓴 바이트 수를 알려줍니다.

비차단 IO는 읽고 쓸 때 스레드가 더 이상 차단될 필요가 없다는 의미입니다. 읽기와 쓰기가 즉시 완료될 수 있으며 스레드는 계속해서 다른 작업을 수행할 수 있습니다.

멀티플렉싱(이벤트 폴링)

비 차단 IO는 빠르지만 문제도 발생합니다. 스레드는 데이터를 읽고 일부를 읽은 후 반환합니다. 남은 데이터? , 데이터 쓰기 중 버퍼가 가득 차서 완전히 쓰여지지 않았습니다. 남은 데이터는 언제 계속 쓰여지나요?

계속 읽거나 계속 쓸 수 있게 되면, 계속 읽거나 계속 쓸 수 있음을 애플리케이션에 알리는 알림을 애플리케이션에 제공해야 합니다. 이 문제를 처리하려면 이벤트 폴링 API가 사용됩니다.

select

운영 체제는 사용자 프로그램에 선택 기능을 제공하며, 출력은 해당 읽기 및 쓰기 이벤트입니다. timeout 매개변수, 스레드가 시간 초과를 기다리는 최대 시간입니다. 이 기간 동안 이벤트가 발생하면 메서드가 즉시 반환되고 스레드는 시간 초과 시간이 초과되면 메서드도 반환됩니다. 이벤트를 획득하면 스레드는 해당 이벤트를 하나씩 처리할 수 있습니다. 이벤트가 처리된 후에도 계속해서 선택 API 폴링을 호출하므로 스레드는 실제로 계속 선택하고 처리하며 되돌아갑니다. 이 무한 루프를 이벤트 루프라고 하며 루프는 사이클입니다.

이벤트 루프 의사코드:

while True
    read_events, write_events = select(read_fds, write_fds, timeout)
    for event in read_events:
        handle_read(event.fd)
    for event in write_events:
        handle_write(event.fd)
    handle_others() # 做其他的逻辑处理，处理定时任务等等

select 함수를 통해 여러 채널 설명자의 읽기 및 쓰기 이벤트를 처리할 수 있으므로 select와 같은 시스템 함수 호출을 다중화 API라고 합니다.

Modern 다중화 API는 운영 체제는 더 이상 select 시스템 호출을 사용하지 않지만 epoll(linux) 및 kqueue(FreeBSD, macosx)를 사용합니다.

epoll을 사용하고 select의 성능이 매우 저하됩니다. 약간의 차이가 있습니다. 위의 의사 코드로 모두 이해할 수 있습니다. 디스크립터에서 이벤트가 발생하면 디스크립터 이벤트가 루프에서 처리됩니다. 오면 select에서 호출하는 읽기 이벤트를 통해서도 알림을 받습니다.

Java의 NIO 기술은 이벤트 폴링이며, 다른 언어에도 이 기술이 있습니다.

Command Queue

Redis는 명령 대기열을 각 클라이언트 소켓과 연결하고, 클라이언트가 보낸 명령은 대기열을 통해 선입선출 순서로 처리됩니다.

응답 대기열

마찬가지로 Redis에서 반환한 결과도 각 클라이언트와 연결된 대기열을 통해 반환됩니다. 대기열이 비어 있으면 당분간 쓰기 이벤트를 얻을 필요가 없습니다. 클라이언트 설명자는 write_fds에서 제거에서 변경된 다음 데이터가 있을 때 설명자를 대기열에 넣습니다. 이렇게 하면 select 시스템 호출이 쓰기 이벤트를 반환할 때 쓸 데이터가 없다는 것을 발견하여 빈 폴링이 발생하는 것을 방지할 수 있습니다. 쓸모없는 폴링 및 시스템 CPU 소비.

예약된 작업

서버는 IO 이벤트에 응답해야 할 뿐만 아니라 애플리케이션 자체의 예약된 작업과 같은 다른 작업도 처리해야 합니다. 스레드가 선택 호출을 차단하고 선택 반환을 기다리는 경우

Redis의 예약된 작업은 최소 힙이라는 데이터 구조에 기록되며 각 주기에서 가장 빠른 작업이 맨 위에 표시됩니다. 힙에서 완료된 작업을 업데이트합니다. 처리가 완료된 후 다시 select가 호출될 때까지 걸리는 시간이 기록됩니다. 이 기간 동안에는 다른 작업이 필요하지 않습니다. 실행 후 Redis는 최대 이 시간 동안 차단되며 시간이 지나면 해당 처리를 수행합니다.

NodeJ와 Nginx의 이벤트 처리 원리는 Redis와 유사합니다.

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

프로그래밍 비디오

를 방문하세요! !

위 내용은 이 문서에서는 Redis의 스레드 IO 모델을 빠르게 이해하는 데 도움이 됩니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!