C 线程、事件循环和大量连接和并发

全部。我正试图找出以最佳方式处理大量并发连接（超过800k）的最佳方法。我决定使用libevent处理套接字上的读/写操作，并将在后端使用一个端口，在非阻塞套接字上处理fd。我的问题在哪里发挥作用：

1） 关于事件库的libevent——例如，如果我要在每个内核上运行一个线程，每个线程都有自己的libevent库，侦听单个fd上的传入连接，那么libevent如何处理在单个fd上触发的多个事件库？我们的想法是，然后接受传入的连接，接受它，并根据特定于该连接的新fd启动一个新的事件库。或者，像我过去那样，运行主程序线程中的主事件库并将传入连接推送到工作线程以处理accept，然后为每个连接创建一个新的事件库，这是正确的方法吗

2） 每个连接的线程数。。。是，还是不是？在过去的实现中，我为每个接受的连接建立了一个1:1线程的模型。最终的结果显然是连接了500个客户端，500个线程加上我用作工作队列的任何线程。然而，我担心一旦我接触到成千上万的标记连接，这可能会引起一个问题。。。有人能证实吗？我还觉得在使用异步IO（如libevent）时，有那么多线程是不必要的，只是增加了比需要更多的开销。。。但我可能错了

---

这是我第一次不得不写一些能够支持如此高的用户负载的东西，我更希望能够从一个坚实的概念设计中从头开始写，作为一种充分理解一切的手段。显然，我可以深入研究一些东西，比如UnrealIRCD或nginx的源代码，并提出一个解决方案，但我真的更愿意从理解我在写什么以及为什么要这样写的角度来做。因此，我们非常感谢您的反馈。

我相信您可能混淆了两种不同的编程模式。如果您使用的是libevent，每个线程将处理数百或数千个连接。有关从何处开始开发针对C10K问题的大容量/并发服务器搜索的更多信息。以下是要开始的页面：

---

顺便说一句，如果你想扩展到800K并发连接，你不应该使用“每个连接线程”模式。

如果你尝试启动800K线程，你几乎肯定会遇到问题；您可以使用一个测试用例来证明这一点。一般的想法是，为了降低每个线程分配上下文和在内核之间切换上下文的成本，您应该从程序可用的CPU内核的数量中得出线程的数量。多线程是一种优化，与许多其他优化一样，如果将其发挥到极致，不仅会失去好处，还会将其他优化推到看不见的地方。先用一个线程编写你的程序，然后放大它…另外，我能给出的三个最明智的词是：使用分析器…我感谢你的反馈。在深入研究libevent2之后，我提出了以下模型：在程序开始时预加载的用户指定的“事件基线程”计数。每个“事件基线程”都有一个与之关联的事件基，并启动事件循环。当连接进入时，我将连接事件基旋转到线程上的每个线程/事件基。这似乎效果很好。我用“每连接一个线程”进行了测试，在20k的连接之后，情况非常糟糕。我已经实现了一个带有代理的调度器来处理所有事件。