使用 epoll 处理多个同时请求答案

【问题标题】：Handing multiple simultaneous requests using epoll使用 epoll 处理多个同时请求
【发布时间】：2015-03-12 06:14:19
【问题描述】：

我正在尝试学习如何使用 epoll 来创建一个服务器，该服务器接收并执行来自客户端的命令（登录、下载文件等）。到目前为止，我已经让程序简单地向客户端发送它收到的所有数据，但我注意到当我尝试实现我列出的命令时，服务器一次只能处理一个请求。

我正在尝试想出一种可以同时处理许多命令的有效方法。到目前为止，我想出的唯一想法是创建一个单独的线程来处理每个请求，但我不确定这是否是最佳解决方案。有什么好的处理方法？

【问题讨论】：

【解决方案1】：

如果你的架构是 epoll + 单线程，那么如果你的命令负载很重，它就会有一些阻塞问题。这就是为什么当某些命令阻塞时redis的性能会下降的原因。

还有其他可能的架构。但在你尝试这些之前，先做一些性能测试。如果 redis 可以在单线程中完成数百万次 OPS，那么您也可以这样做。

epoll + 每个线程的命令：正如您所说。但是当负载增加时，线程的创建和销毁会增加成本。频繁的上下文切换也是一个大问题。

epoll + 线程池：示例想法。但没有上述缺点。

epoll based listener + N*(epoll worker)：这是一个有趣的结构。 epoll 监听器会从用户那里获取请求，但不是直接将作业分配给线程，而是将文件描述符注册到下一个工作人员的 epoll 中。通过这种方式，监听线程被释放并且可以更快地接受连接。

【讨论】：

我不确定“redis”是什么，但听起来很有趣。另外，我真的很喜欢 epoll + 线程的想法。您认为这将如何将性能方面与每个线程的命令进行比较？
另一个小问题，如果我进行epoll +线程池设计，我应该在线程池中放置多少个线程有什么通用规则吗？
redis 或多或少是这个行业中最受欢迎的内存数据存储。你的意思是epoll+线程池？理论上，这比 epoll+（每个线程的命令）要好。性能测试是一个很大的话题。我怀疑你能看到小测试集的差异。
好吧，我猜没有一般规则。在生产中，我们有工具来分析程序并获取上下文切换号并基于此调整程序。
我会建议另一种架构（作为监听器 + N*workers 的扩展）：epoll 监听器 + 消息队列 + 工作者池。但是，如果您计划扩展您的应用程序以承受非常重的负载，这将是有益的 - 消息队列将允许您在集群中的其他进程或计算节点之间分配工作。