Redis의 이벤트 중심 모델은 무엇입니까?

Redis가 기본 소켓 프로그래밍 모델을 사용하지 않는 이유는 무엇입니까?

소켓 모델을 사용하여 네트워크 통신을 구현하는 경우 소켓 생성, 포트 수신, 연결 처리, 요청 읽기 및 쓰기 등 여러 단계를 거쳐야 합니다. 이제 이들의 주요 작업을 자세히 살펴보겠습니다. 소켓 모델의 단점을 분석하는 데 도움이 되는 단계입니다.

우선, 서버와 클라이언트 간 통신이 필요한 경우 서버 측에서 다음 세 단계를 통해 클라이언트 연결을 수신하는 청취 소켓(Listening Socket)을 생성할 수 있습니다. 소켓 함수, 소켓을 생성합니다. 일반적으로 우리는 이 소켓을 활성 소켓이라고 부릅니다.

• 활성 소켓을 현재 서버의 IP 및 수신 포트에 바인딩하기 위해 바인딩 함수를 호출합니다.

• 듣기 함수를 호출하여 바인딩합니다. 활성 소켓은 소켓으로 변환됩니다. 청취 소켓을 종료하고 클라이언트 연결 청취를 시작합니다.

• 위의 세 단계를 완료하면 서버는 클라이언트의 연결 요청을 받을 수 있습니다. 클라이언트의 연결 요청을 적시에 수신하기 위해 클라이언트의 연결 요청을 수신하기 위해 accept 함수가 호출되는 루프 프로세스를 실행할 수 있습니다.

여기서 주의해야 할 점은 accept 함수는 차단 기능이라는 것입니다. 즉, 이때 클라이언트 연결 요청이 없으면 서버 측 실행 프로세스는 항상 accept 함수에서 차단됩니다. 클라이언트 연결 요청이 도착하면 accept는 더 이상 차단되지 않고 연결 요청을 처리하고 클라이언트와 연결을 설정한 후 연결된 소켓을 반환합니다.

마지막으로 서버는 recv 또는 send 함수를 호출하여 방금 반환된 연결된 소켓에서 읽기 및 쓰기 요청을 수신하고 처리하거나 클라이언트에 데이터를 보낼 수 있습니다.

Code:

listenSocket = socket(); //调用socket系统调用创建一个主动套接字
bind(listenSocket); //绑定地址和端口
listen(listenSocket); //将默认的主动套接字转换为服务器使用的被动套接字，也就是监听套接字
while(1) { //循环监听是否有客户端连接请求到来
connSocket = accept(listenSocket);//接受客户端连接
recv(connSocket);//从客户端读取数据，只能同时处理一个客户端
send(connSocket);//给客户端返回数据，只能同时处理一个客户端
}

그러나 위의 코드에서 서버와 클라이언트 간의 통신을 달성할 수 있지만 프로그램은 accept 함수가 호출될 때마다 하나의 클라이언트 연결만 처리할 수 있다는 것을 알 수 있습니다. 따라서 여러 동시 클라이언트 요청을 처리하려면 멀티스레딩을 사용하여 accept 함수를 통해 설정된 여러 클라이언트 연결에 대한 요청을 처리해야 합니다.

이 방법을 사용한 후에는 accept 함수가 연결된 소켓을 반환한 후 스레드를 생성하고 연결된 소켓을 생성된 스레드에 전달해야 합니다. 이 스레드는 이 연결된 소켓에 대한 후속 처리를 담당합니다. 동시에 서버측 실행 프로세스는 accept 함수를 다시 호출하고 다음 클라이언트 연결을 기다립니다.

멀티스레딩:

listenSocket = socket(); //调用socket系统调用创建一个主动套接字
bind(listenSocket); //绑定地址和端口
listen(listenSocket); //将默认的主动套接字转换为服务器使用的被动套接字，也就是监听套接字
while(1) { //循环监听是否有客户端连接请求到来
connSocket = accept(listenSocket);//接受客户端连接
pthread_create(processData, connSocket);//创建新线程对已连接套接字进行处理
}

processData(connSocket){
recv(connSocket);//从客户端读取数据，只能同时处理一个客户端
send(connSocket);//给客户端返回数据，只能同时处理一个客户端
}

이 방법은 서버의 동시 처리 능력을 향상시킬 수 있지만 Redis의 주요 실행 프로세스는 하나의 스레드로 실행되므로 멀티 스레딩을 사용하여 동시 처리 능력을 향상시킬 수는 없습니다. 따라서 이 방법은 Redis에서는 작동하지 않습니다.

Redis가 동시 클라이언트의 처리 기능을 향상시키는 데 도움이 될 수 있는 다른 방법이 있습니까? 이를 위해서는 운영 체제에서 제공하는 IO 다중화 기능을 사용해야 합니다. 기본 소켓 프로그래밍 모델에서 accept 함수는 하나의 수신 소켓에서 클라이언트 연결만 수신할 수 있고, recv 함수는 연결된 소켓에서 클라이언트가 보낸 요청만 기다릴 수 있습니다.

Linux 운영 체제는 실제 응용 프로그램에서 널리 사용되므로 이번 강의에서는 주로 Linux의 IO 다중화 메커니즘을 연구합니다. Select, Poll 및 epoll은 Linux에서 제공하는 IO 다중화 메커니즘의 세 가지 주요 형태입니다. 다음으로 이 세 가지 메커니즘의 구현 아이디어와 사용 방법을 각각 알아보겠습니다. 다음으로 Redis가 네트워크 통신을 구현하기 위해 종종 epoll 메커니즘을 사용하는 이유를 살펴보겠습니다.

선택 및 폴 메커니즘은 IO 다중화를 구현합니다

먼저 선택 메커니즘의 프로그래밍 모델을 이해해 보겠습니다.

그러나 자세히 배우기 전에 IO 다중화 메커니즘에 대해 숙달해야 할 핵심 사항이 무엇인지 알아야 합니다. 이를 통해 다양한 메커니즘 간의 연결과 차이점을 빠르게 파악할 수 있습니다. 실제로 IO 멀티플렉싱 메커니즘을 학습할 때 다음 질문에 답할 수 있어야 합니다. 첫째, 멀티플렉싱 메커니즘이 소켓의 어떤 이벤트를 수신할 것인가? 둘째, 멀티플렉싱 메커니즘은 몇 개의 소켓을 수신할 수 있습니까? 셋째, 소켓이 준비되면 멀티플렉싱 메커니즘이 준비된 소켓을 어떻게 찾나요?

선택 메커니즘

선택 메커니즘에서 중요한 기능은 선택 기능입니다. select 함수의 경우 해당 매개변수에는 모니터링되는 파일 설명자 수 __nfds, 모니터링되는 설명자 readfds, writefds, Exceptfds의 세 가지 컬렉션 및 모니터링 중 대기 차단에 대한 시간 초과 시간 제한이 포함됩니다. select 함수 프로토타입:

int select(int __nfds, fd_set *__readfds, fd_set *__writefds, fd_set *__exceptfds, struct timeval *__timeout)

여기서 주목해야 할 점은 Linux에는 소켓을 고유하게 식별하는 데 사용되는 음수가 아닌 정수인 각 소켓에 대한 파일 설명자가 있다는 것입니다. Linux에서는 멀티플렉싱 메커니즘의 기능에서 파일 설명자를 인수로 사용하는 것이 일반적인 관행입니다. 이 함수는 파일 디스크립터를 통해 해당 소켓을 찾아 모니터링, 읽기, 쓰기 등의 작업을 구현합니다.

select 함수의 세 매개변수는 모니터링해야 하는 파일 설명자 세트를 지정하며, 이는 실제로 모니터링해야 하는 소켓 세트를 나타냅니다. 그럼 왜 3개 세트가 있는 걸까요?

关于刚才提到的第一个问题，即多路复用机制监听的套接字事件有哪些。select 函数使用三个集合，表示监听的三类事件，分别是读数据事件，写数据事件，异常事件。

我们进一步可以看到，参数 readfds、writefds 和 exceptfds 的类型是 fd_set 结构体，它主要定义部分如下所示。其中，fd_mask类型是 long int 类型的别名，__FD_SETSIZE 和 __NFDBITS 这两个宏定义的大小默认为 1024 和 32。

所以，fd_set 结构体的定义，其实就是一个 long int 类型的数组，该数组中一共有 32 个元素（1024/32=32），每个元素是 32 位（long int 类型的大小），而每一位可以用来表示一个文件描述符的状态。了解了 fd_set 结构体的定义，我们就可以回答刚才提出的第二个问题了。每个描述符集合都可以被 select 函数监听 1024 个描述符。

如何使用 select 机制来实现网络通信

首先，我们在调用 select 函数前，可以先创建好传递给 select 函数的描述符集合，然后再创建监听套接字。而为了让创建的监听套接字能被 select 函数监控，我们需要把这个套接字的描述符加入到创建好的描述符集合中。

接下来，我们可以使用 select 函数并传入已创建的描述符集合作为参数。程序在调用 select 函数后，会发生阻塞。一旦 select 函数检测到有就绪的描述符，会立即终止阻塞并返回已就绪的文件描述符数。

那么此时，我们就可以在描述符集合中查找哪些描述符就绪了。然后，我们对已就绪描述符对应的套接字进行处理。比如，如果是 readfds 集合中有描述符就绪，这就表明这些就绪描述符对应的套接字上，有读事件发生，此时，我们就在该套接字上读取数据。

而因为 select 函数一次可以监听 1024 个文件描述符的状态，所以 select 函数在返回时，也可能会一次返回多个就绪的文件描述符。我们可以使用循环处理流程，对每个就绪描述符对应的套接字依次进行读写或异常处理操作。

select函数有两个不足

• 首先，select 函数对单个进程能监听的文件描述符数量是有限制的，它能监听的文件描述符个数由 __FD_SETSIZE 决定，默认值是 1024。

• 其次，当 select 函数返回后，我们需要遍历描述符集合，才能找到具体是哪些描述符就绪了。这个遍历过程会产生一定开销，从而降低程序的性能。

poll机制

poll 机制的主要函数是 poll 函数，我们先来看下它的原型定义，如下所示：

int poll(struct pollfd *__fds, nfds_t __nfds, int __timeout)

其中，参数 *__fds 是 pollfd 结构体数组，参数 __nfds 表示的是 *__fds 数组的元素个数，而 __timeout 表示 poll 函数阻塞的超时时间。

pollfd 结构体里包含了要监听的描述符，以及该描述符上要监听的事件类型。从 pollfd 结构体的定义中，我们可以看出来这一点，具体如下所示。pollfd 结构体中包含了三个成员变量 fd、events 和 revents，分别表示要监听的文件描述符、要监听的事件类型和实际发生的事件类型。

pollfd 结构体中要监听和实际发生的事件类型，是通过以下三个宏定义来表示的，分别是 POLLRDNORM、POLLWRNORM 和 POLLERR，它们分别表示可读、可写和错误事件。

了解了 poll 函数的参数后，我们来看下如何使用 poll 函数完成网络通信。这个流程主要可以分成三步：

• 第一步，创建 pollfd 数组和监听套接字，并进行绑定；

• 第二步，将监听套接字加入 pollfd 数组，并设置其监听读事件，也就是客户端的连接请求；

• 第三步，循环调用 poll 函数，检测 pollfd 数组中是否有就绪的文件描述符。

而在第三步的循环过程中，其处理逻辑又分成了两种情况：

• 如果是连接套接字就绪，这表明是有客户端连接，我们可以调用 accept 接受连接，并创建已连接套接字，并将其加入 pollfd 数组，并监听读事件；

• 如果是已连接套接字就绪，这表明客户端有读写请求，我们可以调用 recv/send 函数处理读写请求。

其实，和 select 函数相比，poll 函数的改进之处主要就在于，它允许一次监听超过 1024 个文件描述符。但是当调用了 poll 函数后，我们仍然需要遍历每个文件描述符，检测该描述符是否就绪，然后再进行处理。

epoll 메커니즘

우선 epoll 메커니즘은 epoll_event 구조를 사용하여 모니터링할 파일 설명자와 모니터링할 이벤트 유형을 기록합니다. 이는 폴 메커니즘에 사용되는 pollfd 구조와 유사합니다.

그래서 epoll_event 구조에는 epoll_data_t 공용 변수와 정수형의 events 변수가 포함되어 있습니다. epoll_data_t 공용체에는 파일 설명자를 기록하는 멤버 변수 fd가 있으며, events 변수는 epoll_data_t 변수의 파일 설명자가 관심을 갖는 이벤트 유형을 나타내기 위해 다양한 매크로 정의 값을 사용합니다. 이벤트 유형에는 다음과 같은 유형이 포함됩니다.

• EPOLLIN: 파일 설명자에 해당하는 소켓에 읽을 데이터가 있음을 나타내는 읽기 이벤트입니다.

• EPOLLOUT: 파일 설명자에 해당하는 소켓에 쓸 데이터가 있음을 나타내는 쓰기 이벤트입니다.

• EPOLLERR: 소켓에 대한 파일 설명자가 잘못되었음을 나타내는 오류 이벤트입니다.

select 또는 poll 기능을 사용할 때 파일 설명자 세트 또는 pollfd 배열을 생성한 후 모니터링해야 하는 파일 설명자를 배열에 추가할 수 있습니다.

하지만 epoll 메커니즘의 경우 먼저 epoll_create 함수를 호출하여 epoll 인스턴스를 생성해야 합니다. 이 epoll 인스턴스는 모니터링할 파일 설명자와 준비된 파일 설명자를 기록하는 두 가지 구조를 내부적으로 유지 관리합니다. 준비된 파일 설명자의 경우 처리를 위해 사용자 프로그램으로 반환됩니다.

따라서 epoll 메커니즘을 사용할 때 select 및 poll을 사용하는 것처럼 어떤 파일 설명자가 준비된지 탐색하고 쿼리할 필요가 없습니다. 따라서 epoll은 select 및 poll보다 더 효율적입니다.

epoll 인스턴스를 생성한 후 epoll_ctl 함수를 사용하여 모니터링되는 파일 설명자에 청취 이벤트 유형을 추가하고 epoll_wait 함수를 사용하여 준비된 파일 설명자를 가져와야 합니다.

이제 우리는 epoll 기능을 사용하는 방법을 이해했습니다. 실제로 epoll은 모니터링되는 설명자 수를 사용자 정의하고 준비된 설명자를 직접 반환할 수 있기 때문에 Redis가 네트워크 통신 프레임워크를 설계하고 구현할 때 epoll 메커니즘의 epoll_create, epoll_ctl 및 epoll_wait와 같은 기능을 기반으로 합니다. 쓰기 이벤트는 네트워크 통신을 위한 이벤트 기반 프레임워크를 구현하기 위해 캡슐화 및 개발되었습니다. 따라서 Redis는 단일 스레드에서 실행되지만 여전히 높은 동시성 클라이언트 액세스를 효율적으로 처리할 수 있습니다.

Reactor 모델의 작동 메커니즘

Reactor 모델은 네트워크 서버에서 높은 동시성 네트워크 IO 요청을 처리하는 데 사용되는 프로그래밍 모델입니다. 모델 기능:

• 세 가지 유형의 이벤트 처리, 즉 연결 이벤트, 쓰기. 이벤트 및 읽기 이벤트 ;

• 세 가지 주요 역할, 즉 리액터, 수락자 및 처리기입니다.

Reactor 모델은 클라이언트와 서버 간의 상호 작용 프로세스를 다루며, 이 세 가지 유형의 이벤트는 클라이언트와 서버 간의 상호 작용 중에 서버 측에서 다양한 유형의 요청에 의해 트리거되는 보류 이벤트에 해당합니다.

• 클라이언트가 서버와 상호 작용하려고 하면 클라이언트는 연결을 설정하기 위해 서버에 연결 요청을 보냅니다. 이는 서버의 링크 이벤트에 해당하며 연결이 설정되면 클라이언트는 다음을 보냅니다. 서버에 요청을 보내 데이터를 읽습니다. 서버가 읽기 요청을 처리할 때 서버의 쓰기 이벤트에 해당하는 데이터를 다시 클라이언트에 써야 합니다. 클라이언트가 서버에 읽기 또는 쓰기 요청을 보내더라도 서버는 요청 내용을 읽어야 합니다. , 여기서 읽기 또는 쓰기 요청은 서버 측의 읽기 이벤트에 해당합니다.

• 세 가지 주요 역할:

• 먼저 연결 이벤트는 수신을 담당하는 수락자에 의해 처리됩니다. 연결을 수신한 후 네트워크 연결에서 후속 읽기 및 쓰기 이벤트를 처리하기 위한 핸들러가 생성됩니다.

두 번째로 읽기 및 쓰기 이벤트는

• 마지막으로 높은 동시성 시나리오, 연결 이벤트, 읽기 및 쓰기 이벤트가 동시에 발생하므로 이벤트를 구체적으로 수신하고 배포하는 역할, 즉 리액터 역할이 필요합니다. 연결 요청이 있으면 리액터는 생성된 연결 이벤트를 처리를 위해 수락자에게 넘겨줍니다. 읽기 또는 쓰기 요청이 있으면 리액터는 처리를 위해 읽기 및 쓰기 이벤트를 핸들러에 넘겨줍니다.

• 이제 이 세 가지 역할이 이벤트 모니터링, 전달 및 처리를 중심으로 상호 작용한다는 것을 알았으니 프로그래밍할 때 이 세 가지 역할의 상호 작용을 어떻게 실현할 수 있을까요? 이는 이벤트 드라이빙과 불가분의 관계입니다.

Reactor 모델을 구현할 때 작성해야 하는 전반적인 코드 제어 로직을 이벤트 중심 프레임워크라고 합니다. 이벤트 기반 프레임워크는 이벤트 초기화와 이벤트 캡처, 오프로딩 및 처리의 기본 루프라는 두 부분으로 구성됩니다. 간단히 말해서.

• 이벤트 초기화는 서버 프로그램이 시작될 때 실행됩니다. 주요 기능은 모니터링해야 하는 이벤트 유형과 이러한 유형의 이벤트에 해당하는 핸들러를 생성하는 것입니다. 서버가 초기화를 완료하면 그에 따라 이벤트 초기화가 완료되며 서버 프로그램은 이벤트 캡처, 배포 및 처리의 메인 루프에 들어가야 합니다.

  while 루프를 메인 루프로 사용하세요. 그런 다음 이 메인 루프에서 발생한 이벤트를 캡처하고, 이벤트 유형을 결정하고, 이벤트 유형에 따라 초기화 중에 생성된 이벤트 핸들러를 호출하여 실제로 이벤트를 처리해야 합니다.

  예를 들어 연결 이벤트가 발생하면 서버 프로그램은 클라이언트와의 연결을 생성하기 위해 억셉터 처리 함수를 호출해야 합니다. 읽기 이벤트가 발생하면 서버 프로그램이 특정 요청 처리 기능을 호출하여 클라이언트 연결에서 요청 내용을 읽어 읽기 이벤트 처리를 완료했음을 나타냅니다.

  Reactor 모델의 기본 작동 메커니즘: 클라이언트의 다양한 요청 유형은 세 가지 유형의 이벤트(서버 측에서 연결, 읽기 및 쓰기)를 트리거합니다. 이 세 가지 유형의 이벤트에 대한 모니터링, 배포 및 처리는 다음과 같습니다. 세 가지 유형의 역할(리액터, 수락자 및 핸들러)에 의해 수행됩니다. 완료되면 이 세 가지 유형의 역할은 이벤트 중심 프레임워크를 통해 상호 작용 및 이벤트 처리를 구현합니다.

위 내용은 Redis의 이벤트 중심 모델은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!