在c++网络编程中几乎都会使用epoll模式，epoll提供了两种触发模式ET(边缘触发)和LT(水平触发 默认的触发模式)。边缘触发就是当有可读事件之后如何一次没有读取完所有数据那么epoll不会在触发可读事件，只有再次从不可读变为可读才会再次触发可读，可写也是同样的道理。水平触发就是只要可读就会不断触发可读事件，只要可写就会不断触发可写事件。所以一般大并发服务器都会使用ET模式，这样比LT模式更高效（我在实际项目中验证过）。那在ET模式我们不可能对一个句柄进行无限次的读取，因为一个句柄读取过多可能导致其他句柄饿死，一般会在一次循环中读取10次或者20次等，那如果这个时候句柄依旧可读应该如何处理，因为本次不读完那么epoll的可读事件将不会在触发，其实可以简单的再次EPOLLMOD，这样在下次循环的时候将会再次触发可读事件。发送数据的处理方式是直接调用send函数发送，如果返回错误就将数据放入等待发送队列，下次触发可写事件在发送数据。这样的处理方式比较简单可直观，不用在句柄依旧可读和可写的情况下自己保存这些句柄。那通过EPOLLMOD是否会降低epoll的效率了，答案是不会，因为这种操作不会频繁的触发。我自己项目中一个进程中包含网关，数据库和逻辑处理也就是说只有一个进程的游戏服务器单服可以负载8000+的人，所以如果独立进程的网关这种处理1万并发应该是毫无压力的。
ps：页游一般单服导量3000人左右，H5游戏单服导量更少，所以服务器架构在满足需求的情况下尽量简单我觉得是最好的，我们项目现在只有一个进程，开发效率比那种单服需要五六跟进程的项目提高20%左右，最近一年基本上后端我一个人应当前端3个人开发无压力。我自己负责架构，功能开发，平台对接，线上问题处理都能够轻松搞定，何乐而不为。
来源：CSDN
作者：m08090420
链接：https://blog.csdn.net/m08090420/article/details/103829612