开局一张图！
上图是盗用自《Linux多线程服务端编程,使用muduo C++网络库》一书6.6.2章节（以及下面的时序图也是盗用该书的图）。该图列举出大部分常用的网络编程模型，当然了，这里并没有列出Boost.Asio的proactor模式。其中表中的“互通”是指多个客户端（连接）间是否能方便地交换数据，如chat聊天程序。我们的evpp库实际上是用到了“方案9”，方案9的时序图如下：
可以看出，每一个线程有一个EventLoop处理事件。这种方案是典型的“one loop per thread”流程，有一个“主EventLoop”负责accept连接，然后把连接通过round-robin（轮询调度）挂到底下的多个“子EventLoop”中（EventLoopThreadPool），每个连接都是由一个“子EventLoop”完成的，能保证请求的顺序性，也可以充分利用CPU，防止出现一个reactor的处理能力饱和，而且EventLoop线程池线程数量固定，不会因为连接数过多到达临界点（线程太多导致操作系统线程调度不过来）而性能下降！
另外还有一种网络编程模型比较常用，就是“方案8”，这个模型在muduo中有现成方案，而在evpp中需要自己实现，时序图如下：
这种方案，只有一个EventLoop，但它把计算密集的部分（decode、compute、encode）分派到一个线程池中处理，处理完后再返回到EventLoop中，这样即使decode、compute、encode这三部分是阻塞的也不影响并发连接，正因为是异步处理，导致打乱了返回的顺序性，也即连接1比连接2先到，但有可能连接2先返回数据。如果处理的事情没有优先级之分或者计算密集型（大部分时间都是处于计算中）可以使用这种方案，如果有优先级之分，应该使用方案9，方案9算是一个各方面都比较均衡的网络编程模式，evpp库就优先使用这种模式。
evpp中比较重要的基础类有：
EventLoop
EventWatcher
Buffer等
EventLoop相关的类包含EventLoop、EventLoopThread和EventLoopThreadPool等类，它们提供事件循环、事件分发、为reactor网络编程模式提供一个基础框架。也提供了定时器，以及RunInLoop等接口，RunInLoop可在多线程环境下被调用，在本eventloop的IO线程内执行某个用户任务回调。我们提倡one loop per thread，顾名思义每个线程只能有一个EventLoop对象，因此EventLoop的构造函数会检查当前线程是否已经创建了其他EventLoop对象，遇到错误就终止程序。
EventWatcher相关的类包含PipeEventWatcher、TimerEventWatcher和SignalEventWatcher能够注册管道、超时以及信号事件，底层是libevent2库。
Buffer类则是类似libevent2中的evbuffer，供应用层读写，底下的socket读写操作也会频繁使用它。
来源：oschina
链接：https://my.oschina.net/u/4257651/blog/4464138