IOCP模型与EPOLL模型的比较（转）

转自博客：http://www.cnblogs.com/lancidie/archive/2013/05/02/3054063.html

一：IOCP和Epoll之间的异同。
异：
1：IOCP是WINDOWS系统下使用。Epoll是Linux系统下使用。
2：IOCP是IO操做完毕以后，经过Get函数得到一个完成的事件通知。
Epoll是当你但愿进行一个IO操做时，向Epoll查询是否可读或者可写，若处于可读或可写状态后，Epoll会经过epoll_wait进行通知。
3：IOCP封装了异步的消息事件的通知机制，同时封装了部分IO操做。但Epoll仅仅封装了一个异步事件的通知机制，并不负责IO读写操做。Epoll保持了事件通知和IO操做间的独立性，更加简单灵活。
4： 基于上面的描述，咱们能够知道Epoll不负责IO操做，因此它只告诉你当前可读可写了，而且将协议读写缓冲填充，由用户去读写控制，此时咱们能够作出额 外的许多操做。IOCP则直接将IO通道里的读写操做都作完了才通知用户，当IO通道里发生了堵塞等情况咱们是没法控制的。

同：
1：它们都是异步的事件驱动的网络模型。
2：它们均可以向底层进行指针数据传递，当返回事件时，除可通知事件类型外，还能够通知事件相关数据。

二：描述一下IOCP:
扯远点。首先传统服务器的网络IO流程以下：
接到一个客户端链接->建立一个线程负责这个链接的IO操做->持续对新线程进行数据处理->所有数据处理完毕->终止线程。
可是这样的设计代价是：
1：每一个链接建立一个线程，将致使过多的线程。
2：维护线程所消耗的堆栈内存过大。
3：操做系统建立和销毁线程过大。
4：线程之间切换的上下文代价过大。
此时咱们能够考虑使用线程池解决其中3和4的问题。这种传统的服务器网络结构称之为会话模型。
后来咱们为防止大量线程的维护，建立了I/O模型，它被但愿要求能够:
1：容许一个线程在不一样时刻给多个客户端进行服务。
2：容许一个客户端在不一样时间被多个线程服务。
这样作的话，咱们的线程则会大幅度减小，这就要求如下两点：
1：客户端状态的分离，以前会话模式咱们能够经过线程状态得知客户端状态，但如今客户端状态要经过其余方式获取。
2：I/O请求的分离。一个线程再也不服务于一个客户端会话，则要求客户端对这个线程提交I/O处理请求。
那么就产生了这样一个模式，分为两部分:
1：会话状态管理模块。它负责接收到一个客户端链接，就建立一个会话状态。
2：当会话状态发生改变，例如断掉链接，接收到网络消息，就发送一个I/O请求给 I/O工做模块进行处理。
3：I/O工做模块接收到一个I/O请求后，从线程池里唤醒一个工做线程，让该工做线程处理这个I/O请求，处理完毕后，该工做线程继续挂起。
上面的作法，则将网络链接 和I/O工做线程分离为两个部分，相互通信仅依靠 I/O请求。
此时可知有如下一些建议：
1：在进行I/O请求处理的工做线程是被唤醒的工做线程，一个CPU对应一个的话，能够最大化利用CPU。因此 活跃线程的个数 建议等于 硬件CPU个数。
2：工做线程咱们开始建立了线程池，免除建立和销毁线程的代价。由于线程是对I/O进行操做的，且一一对应，那么当I/O所有并行时，工做线程必须知足I/O并行操做需求，因此 线程池内最大工做线程个数 建议大于或者等于 I/O并行个数。
3：可是咱们可知CPU个数又限制了活跃的线程个数，那么线程池过大意义很低，因此按常规建议 线程池大小 等于 CPU个数*2 左右为佳。例如，8核服务器建议建立16个工做线程的线程池。
上面描述的依然是I/O模型并不是IOCP，那么IOCP是什么呢，全称 IO完成端口。
它是一种WIN32的网络I/O模型，既包括了网络链接部分，也负责了部分的I/O操做功能，用于方便咱们控制有并发性的网络I/O操做。它有以下特色：
1：它是一个WIN32内核对象，因此没法运行于Linux.
2：它本身负责维护了工做线程池，同时也负责了I/O通道的内存池。
3：它本身实现了线程的管理以及I/O请求通知，最小化的作到了线程的上下文切换。
4：它本身实现了线程的优化调度，提升了CPU和内存缓冲的使用率。
使用IOCP的基本步骤很简单：
1：建立IOCP对象，由它负责管理多个Socket和I/O请求。CreateIoCompletionPort须要将IOCP对象和IOCP句柄绑定。
2：建立一个工做线程池，以便Socket发送I/O请求给IOCP对象后，由这些工做线程进行I/O操做。注意，建立这些线程的时候，将这些线程绑定到IOCP上。
3：建立一个监听的socket。
4：轮询，当接收到了新的链接后，将socket和完成端口进行关联而且投递给IOCP一个I/O请求。注意：将Socket和IOCP进行关联的函数和建立IOCP的函数同样，都是CreateIoCompletionPort，不过注意传参必然是不一样的。
5：由于是异步的，咱们能够去作其余，等待IOCP将I/O操做完成会回馈咱们一个消息，咱们再进行处理。
其中须要知道的是：I/O请求被放在一个I/O请求队列里面，对，是队列，LIFO机制。当一个设备处理完I/O请求后，将会将这个完成后的I/O请求丢回IOCP的I/O完成队列。
咱们应用程序则须要在GetQueuedCompletionStatus去询问IOCP，该I/O请求是否完成。
其中有一些特殊的事情要说明一下，咱们有时有须要人工的去投递一些I/O请求，则须要使用PostQueuedCompletionStatus函数向IOCP投递一个I/O请求到它的请求队列中。

三：网络游戏服务器注意事项，优化措施
1：IO操做是最大的性能消耗点，注意优化余地很大。
2：算法数据结构。排序寻路算法的优化。list,vector,hashmap的选择。大数据寻址，不要考虑遍历，注意考虑hash.
3：内存管理。重载new/delete，内存池，对象池的处理。
4：数据的提早准备和即时计算。
5：CPU方面的统计监视。逻辑帧计数（应当50ms之内）。
6：预分配池减小切换和调度，预处理的线程池和链接池等。
7：基与消息队列的统计和信息监视框架。
8：CPU消耗排名：第一AOI同步，第二网络发包I/O操做，第三技能/BUFF断定计算处理，第四定时器的频率。
9：内存泄露检测，内存访问越界警戒，内存碎片的回收。
10：内存消耗排名：第一玩家对象包括其物品，第二网络数据缓冲。
11：注意32位和64位的内存容错。
12：减小没必要要的分包发送。
13：减小重复包和重拷贝包的代价。
14：建议分紧急包（马上发送）和非紧急包（定时轮训发送）。
15：带宽消耗排名：第一移动位置同步，第二对象加载，第三登录突发包，第四状态机定时器消息。
16：客户端可作部分预判断机制，部分操做尽可能分包发送。
17：大量玩家汇集时，部分非紧急包进行丢弃。
18：注意数据库单表内key数量。
19：活跃用户和非活跃用户的分割存取处理。
20：控制玩家操做对数据库的操做频率。
21：注意使用共享内存等方式对数据进行安全备份存储。
22：注意安全策略，对内网进行IP检查，对日志进行记录，任意两环点内均使用加密算法会更佳。
23：实时注意对网关，数据库等接口进行监察控制。
24：定时器应当存储一个队列，而非单向定位。
25：九宫格数据同步时，不须要直接进行九宫格的同步，对角色加一个AOI，基于圆方碰撞原理，抛弃没必要要的格信息，可大幅节省。
26：客户端作部分的预测机制，服务器检测时注意时间戳问题。
27：按期心跳包，检查死连接是必要的。
28：为了实现更加负责多种类的AI，AI寻路独立服务器设计已是必须的了。其次须要考虑的是聊天，同步。
29：服务器内网间能够考虑使用UDP。
30：注意全部内存池，对象池等的动态扩张分配。

1：之内存换取CPU的理念。
2：NPC不死理念。(只会disable)
3：动态扩展理念，负载均衡理念。
4：客户端不可信理念。
5：指针数据，消息均不可信理念。