我已经阅读了C10K doc以及许多关于扩展套接字服务器的相关文章.所有道路都指向以下内容：
>避免“每个连接的线程”的经典错误.@H_404_4@>首选选择epoll.@H_404_4@>同样,unix中的遗留异步io机制可能很难使用.
我的简单TCP服务器只是在专用端口上侦听侦听套接字上的客户端连接.收到新连接后,解析请求,然后发回响应.然后优雅地关闭套接字.
我想我可以很好地处理如何使用epoll在单个线程上扩展它.只有一个循环调用epoll_wait作为listen套接字以及现有的客户端连接.返回后,代码将处理新的创建新客户端连接以及管理现有连接的状态,具体取决于刚刚发出信号的套接字.也许还有一些逻辑来管理连接超时,正常关闭套接字以及为每个连接分配有效的资源.看起来很简单.
但是如果我想扩展它以利用多个线程和多个cpu内核呢？想到的核心理念是：
一个专用线程,用于侦听TCP侦听套接字上的传入连接.然后是一组N个线程(或线程池)来处理所有活动的并发客户端连接.然后发明一些线程安全的方法,其中listen线程将“新的连接(套接字)”“分派”到一个可用的工作线程. (Windows中的ala IOCP).工作线程将在其处理的所有连接上使用epoll循环来执行单线程方法将执行的操作.
我是在正确的轨道上吗？或者是否有一个标准的设计模式用于在多个线程上使用epoll执行TCP服务器？
关于监听线程如何将新连接分派给线程池的建议？
第一个问题是,你需要这个吗？如果您通过产生线程来处理每个传入的请求来轻松应对现有流量,那么继续这样做.代码将更简单,并且您的所有库都可以很好地运行.
正如我上面提到的,同时处理杂乱请求可能很复杂.如果要在单个循环中执行此操作,则还需要在生成响应时保证cpu饥饿.
如果您的响应生成成本很高,那么您提出的调度模型是典型的第一步解决方案.您可以分叉或使用线程.在选择池化机制时,不应考虑分叉或生成线程的成本：而应使用这种机制来限制或订购系统上的负载.
将插座分批安装到多个epoll环上是过分的.如果您非常绝望,请使用多个流程.请注意,可以从多个线程和进程接受套接字.
