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