《简述Linux平台下服务器框架的搭建思路（一）》

如果想搭建一个类似于Muduo的TCP服务器框架，具有高并发的服务能力，能够将单机服务做到极致，那么如下几点是需要我们去考虑的：
1、采用Reactor模式，使用Epoll/Poll作为事件的分发器。
2、必须支持多线程，能够将套接字上的IO事件分离到多个线程上，发挥多核CPU的优势。
3、封装套接字上的读写操作，因为涉及到多个客户端套接字和大量数据的读写，直接调用操作系统提供的Read/Write函数，会显得十分不友好。
服务器的结构和框架虽然复杂，但也是由很多单元和模块组成的，就好比再复杂的机器也是很多零部件组成的，咱们摸清楚了每个零部件的构造和结构，自然就能把整个机器的工作原理给整明白。
现在逐一介绍TCP服务器框架的每个零部件的构造和原理：

一、EventLoop对象
EventLoop顾名思义就是事件循环，也就是一个不断去监听/处理客户端事件的循环，它和一个线程进行绑定，也正是One Loop One Thread思想的体现，每个线程和一个EventLoop进行绑定，专门去处理一个客户端的读、写或者建立连接的请求。
二、Channel对象
既然EventLoop对象是专门处理客户端事件的对象，那么如何把客户端的读写请求、连接请求注册到EventLoop中去呢？此时我们抽象一个Channel对象来封装这些客户端请求，但不限于这些请求，其他的也可以抽象成一个Channel对象，只要EventLoop需要的，都可以抽象成Channel对象，EventLoop就好比一个炼丹炉。
三、ChannelMap对象
ChannelMap对象也就是socket和Channel的一个键值对，当有事件发生时，可以根据socket找到对应Channel对象中的回调函数。
四、Acceptor监听器
从名字也能看出来，Acceptor是专门用于监听客户端请求的一个监听器，Acceptor最终会构建一个连接队列出来，以供EventLoop去处理；此时我们应该想到Acceptor也可以抽象成一个Channel对象注册到EventLoop中去。
五、Event_Dispatcher
因为EventLoop是处理事件的大熔炉，那么socket上的事件（可读、可写、连接等事件）的检测和分发是不是要抽象成一个Dispatcher来进行处理，不可能直接使用Epoll/Poll模型的接口暴露给上层应用去调用。
六、线程池ThreadPool
现在服务器主流的设计思想便是主从Reactor模式，主Reactor只负责和客户端建立连接，从Reactor负责处理已连接套接字上的IO读写事件，因为服务器主要的工作是处理socket上的IO读写事件，因此ThreadPool便是专门为IO读写事件服务的。
七、Tcp_Connection对象
Tcp_Connection对象表示的是一个TCP连接，也是我们应用层和服务器框架直接接触的一个对象，我们应用层定义的回调函数可以传递到Tcp_Connection对象中去，把底层处理好的数据或结果回调上来。
八、Buffer（发送缓冲区/接受缓冲区）
定义一段缓冲区，专门用于处理socket上IO读写数据，或者存储socket上待发送/已接受的数据，起到一个缓冲的作用，在muduo设计中，还对每个Buffer设计了高低水位的概念。
到目前为止，介绍完了TCP服务器框架中涉及到的元素和基本结构，可以用如下图描述出各结构如何组装出一个TCP服务器框架出来。