redis 中的 reactor 模型

Reactor模式

C10K问题

考虑这样一个问题：有10000个client须要连上一个server并保持TCP连接。client会不定时的发送请求给server，server收到请求后需及时处理并返回结果。我们应该怎么解决?

方案一：我们使用一个线程来监听，当一个新的client发起连接时，建立连接并new一个线程来处理这个新连接。

缺点：当client数量非常多时，服务端线程数过多，即便不压垮server，因为CPU有限其性能也极其不理想。因此此方案不可用。

方案二：我们使用一个线程来监听，当一个新的client发起连接时，建立连接并new一个线程来处理这个新连接。

缺点：当client数量非常多时，服务端线程数过多，即便不压垮server，因为CPU有限其性能也极其不理想。因此。一个线程只处理一个client连接不管怎样都是不可接受的。

3.那能不能一个线程处理多个连接呢？该线程轮询每一个连接，假设某个连接有请求则处理请求。没有请求则处理下一个连接，这样能够实现吗？当然有，可以通过I/O多路复用技术来解决问题。

I/O多路复用技术

现代的UNIX操作系统提供了select/poll/kqueue/epoll这种系统调用，这些系统调用的功能是：你告知我一批套接字。当这些套接字的可读或可写事件发生时，我通知你这些事件信息。

套接字

在UNIX系统上，一切皆文件。套接字也不例外。每个套接字都有相应的fd（即文件描写叙述符）。我们简单看看这几个系统调用的原型。

select

select(int nfds, fd_set *r, fd_set *w, fd_set *e, struct timeval *timeout) 对于select()，我们须要传3个集合。r，w和e。当中，r表示我们对哪些fd的可读事件感兴趣，w表示我们对哪些fd的可写事件感兴趣。

每一个集合事实上是一个bitmap，通过0/1表示我们感兴趣的fd。比如，我们对于fd为6的可读事件感兴趣，那么r集合的第6个bit须要被设置为1。

这个系统调用会堵塞，直到我们感兴趣的事件（至少一个）发生。调用返回时。内核相同使用这3个集合来存放fd实际发生的事件信息。

也就是说，调用前这3个集合表示我们感兴趣的事件，调用后这3个集合表示实际发生的事件。

为什么要引入poll？

select为最早期的UNIX系统调用。它存在4个问题：1）这3个bitmap有限制大小（FD_SETSIZE，通常为1024）；2）因为这3个集合在返回时会被内核改动，因此我们每次调用时都须要又一次设置；3）我们在调用完毕后须要扫描这3个集合才干知道哪些fd的读/写事件发生了，普通情况下全量集合比較大而实际发生读/写事件的fd比較少。效率比較低下。4）内核在每次调用都须要扫描这3个fd集合，然后查看哪些fd的事件实际发生，在读/写比較稀疏的情况下相同存在效率问题。

因为存在这些问题，于是人们对select进行了改进。从而有了poll。

poll(struct pollfd *fds, int nfds, int timeout)

struct pollfd {
    int fd;
    short events;
    short revents;
}

poll调用须要传递的是一个pollfd结构的数组。调用返回时结果信息也存放在这个数组里面。 pollfd的结构中存放着fd、我们对该fd感兴趣的事件(events)以及该fd实际发生的事件(revents)。

poll传递的不是固定大小的bitmap，因此select的问题1攻克了。poll将感兴趣事件和实际发生事件分开了，因此select的问题2也攻克了。但select的问题3和问题4仍然没有解决。

select问题3比較easy解决，仅仅要系统调用返回的是实际发生对应事件的fd集合，我们便不须要扫描全量的fd集合。

对于select的问题4，我们为什么须要每次调用都传递全量的fd呢？内核可不能够在第一次调用的时候记录这些fd，然后我们在以后的调用中不须要再传这些fd呢？

问题的关键在于无状态!!!

对于每一次系统调用，内核不会记录下不论什么信息。所以每次调用都须要反复传递同样信息。上帝说要有状态。所以我们有了epoll和kqueue。

epoll状态

int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

epoll_create的作用是创建一个context，这个context相当于状态保存者的概念。

epoll_ctl的作用是，当你对一个新的fd的读/写事件感兴趣时，通过该调用将fd与对应的感兴趣事件更新到context中。

epoll_wait的作用是，等待context中fd的事件发生。

int kqueue(void);
int kevent(int kq, const struct kevent *changelist, int nchanges, struct kevent *eventlist, int nevents, const struct timespec *timeout);

与epoll同样的是，kqueue创建一个context。与epoll不同的是。kqueue用kevent取代了epoll_ctl和epoll_wait。

epoll和kqueue攻克了select存在的问题。通过它们，我们能够高效的通过系统调用来获取多个套接字的读/写事件，从而解决一个线程处理多个连接的问题。

Reactor的定义

通过select/poll/epoll/kqueue这些I/O多路复用函数库。我们攻克了一个线程处理多个连接的问题，但整个Reactor模式的完整框架是如何的呢？參考这篇paper。我们能够对Reactor模式有个完整的描写叙述。 Handles ：表示操作系统管理的资源，我们能够理解为fd。

Synchronous Event Demultiplexer ：同步事件分离器。堵塞等待Handles中的事件发生。

Initiation Dispatcher ：初始分派器，作用为加入Event handler（事件处理器）、删除Event handler以及分派事件给Event handler。

也就是说，Synchronous Event Demultiplexer负责等待新事件发生，事件发生时通知Initiation Dispatcher，然后Initiation Dispatcher调用event handler处理事件。

Event Handler ：事件处理器的接口

Concrete Event Handler ：事件处理器的实际实现，并且绑定了一个Handle。由于在实际情况中，我们往往不止一种事件处理器，因此这里将事件处理器接口和实现分开，与C++、Java这些高级语言中的多态类似。

以上各子模块间协作的步骤描写叙述例如以下： 1.我们注冊Concrete Event Handler到Initiation Dispatcher中。 2.Initiation Dispatcher调用每一个Event Handler的get_handle接口获取其绑定的Handle。 3.Initiation Dispatcher调用handle_events開始事件处理循环。在这里，Initiation Dispatcher会将步骤2获取的全部Handle都收集起来，使用Synchronous Event Demultiplexer来等待这些Handle的事件发生。 4.当某个（或某几个）Handle的事件发生时，Synchronous Event Demultiplexer通知Initiation Dispatcher。 5.Initiation Dispatcher依据发生事件的Handle找出所相应的Handler。 6.Initiation Dispatcher调用Handler的handle_event方法处理事件。

另外，该文章举了一个分布式日志处理的样例，感兴趣的同学能够看下。通过以上的叙述，我们清楚了Reactor的大概框架以及涉及到的底层I/O多路复用技术。

wittyResry / myIssue