libevent源码剖析（一）——reactor模式

在前面讲过IO模型，就是为了能更好的理解reactor模型。因为整个libevent就是reactor，所以要先对reactor的基础做一个理解。IO基础。在看完这个后，就可以正式开始深入这个模式。

reactor是什么？

首先我们需要知道的是，普通函数调用时的机制：程序调用某个函数，进入函数体执行，主程序等待，函数在返回值后便结束函数体执行，程序拿着结果继续进行执行。
reactor与普通函数不同，应用程序需要将提前提供自己的接口并注册到reactor上，当相应事件发生的时候，reactor就调用这些接口，也就是回调函数，完成工作。
举个例子：
普通函数是：你去小餐厅吃饭，点完菜后只能等，然后一遍遍询问，我的菜好了没，我的菜是什么什么。
reactor： 你去餐厅就要领一个编号，点完菜之后等着就可以了，当菜好了的时候，就会根据编号送到你面前。
直白点来说，普通函数调用时只能等待，而reactor则可以在过程中干其他事。

怎么实现reactor

根据上面的例子，我们需要点菜，需要号，这个菜还得保证在这个餐厅有。这其实就是reactor所需的东西：事件源（菜），reactor框架（不是有餐厅都可以这样操作），多路复用（号），事件处理程序（这个菜可以做）。

上图就是整个的流程框架，我们一步步来分析：

1. 事件源：也就是我们发生的事情。linux上其实就是文件描述符，或者还有socket等。就是程序需要关心的事情，常见的就是IO了。
2. event demultiplexer：也叫多路分发机制。这里就用到之前讲的IO复用了。这个需要好好解释下，我也是在里面花了比较大的功夫。
   前面说过，程序首先要将事件源和事件注册到ed上，当有事件到达时，ed就会通知，有事件已经就绪，对应的程序就会对此事件进行处理。
   其实就是select或epoll，我注册了文件描述符，当有文件描述符就绪时，我就会收到通知，然后进行处理。处理的时候自然是非阻塞的，因为我们使用了IO复用。你干你的，我查我的。
   libevent在使用的时候没有出现IO复用，因为它在结构体中进行了封装，然后暴露出一个接口直接使用就可以了。具体的到了源码部分分析。
3. reactor：进行事件管理，内部注册和注销事件（多路分发），还进行事件循环，也就是轮询，事件就绪时，就会检测到，然后调用注册时的回调函数处理。在libevent中就是eventbase结构体。
4. 事件处理：顾名思义，进行事件处理，所以要对应事件，他提供一组接口，每个接口对应一个事件，reactor在调用回调函数时，就会选择相应的接口，执行相应的事件处理。也就是libevent中的event结构体。

其实reactor很同意搞不懂是什么东西，我来用我的理解试着讲述一下这个事。reactor类似一个餐厅，你在进入我餐厅后，我才给你服务，这也就是应用程序要提供事件源和事件，你得进来，我才能给你服务。进来后每个人点完菜后会给你一个牌子，也就是注册，这样你就进入了我们的服务范围。你不能把自己想成客人，你可以把自己想成主程序，reactor是服务员，他会不断检查每个号的菜是否就绪。这样你不需要一直问我的菜好了没，服务员会帮你检查。期间你可以玩手机、转菜单、唠唠嗑。当后厨收到编号后，就会根据编号上菜单去炒菜，这就是事件接口调用。当就绪后，把菜端到你面前就可以了。
作为程序设计者，我们要做的最好不是我的主程序在某个环节等着，尤其是这种高并发场所，想象一下10000万个人等在你后面的场景。多线程是一种解决方案，来一个我就开一个线程。但是，10000个线程，切换时开销挺大的，所以我们把这个事交给专业的内核来做，你帮我检查，我就一直执行就好了。这就是reactor设计模式的核心。

小记加总结

了解reactor才能理解libevent的核心，在学习一个东西的时候，就要有灵感和想法记录，比如我在想这个的时候，就想了能不能不用多线程，但是可以用线程池，也就是reactor+线程池的模式是不是会更快一些，毕竟多了几个人一起干，而且切换代价也小，应该比起整体来说不算负担，在性能上会提升。
哈哈哈哈，查了查，发现确实有这个工作模式。悔自己生的晚，不然我也是一种模式的开创者。继续学习，以后有机会，加油。