c++ - 每个连接的线程与 react 器模式(带有线程池)？

Question

我想编写一个简单的多人游戏作为我的 C++ 学习项目的一部分。

所以我想，既然我在做，我想把它做好，而不是仅仅完成它。

如果我理解正确的话:Apache 使用 Thread-per-connection 架构，而 nginx 使用事件循环，然后专用一个 worker [x]对于传入的连接。我猜 nginx 更聪明，因为它支持更高的并发级别。对吧？

我也遇到过这个clever analogy ，但我不确定它是否可以应用于我的情况。这个类比似乎也非常理想主义。我很少看到我的计算机以 100% 的 CPU 运行(即使打开了无数个 Chrome 选项卡、Photoshop 和其他未同时运行的东西)

另外，我遇​​到了一个 SO 帖子(不知何故它从我的历史中消失了)，用户询问他们应该使用多少线程，其中一个答案是拥有大约 700 个甚至高达 10,000 个线程是完全可以接受的线程。不过，这个问题与 JVM 有关。

因此，让我们估计大约 5,000 名用户的虚构用户群。哪种方法应该是“最并发”的？

1. 在单个线程中运行所有内容的 react 器模式。
2. 带有线程池的 react 器模式(大约，您建议线程池应该有多大？
3. 为每个连接创建一个线程，然后销毁连接关闭的线程。

我承认选项 2 听起来对我来说是最好的解决方案，但我对这一切都很陌生，所以我可能有点天真并遗漏了一些明显的缺陷。此外，这听起来可能很难实现。

PS:我正在考虑使用 POCO C++ Libraries .建议任何替代库(如 boost )对我来说很好。但是，许多人说 POCO 的库非常干净且易于理解。所以，我最好使用那个，这样我就可以了解我正在使用的如何。

Answer 1

如果编写正确，响应式应用程序肯定会更好地扩展。这意味着

• 从不阻塞在响应式线程中:
  • 任何阻塞都会严重降低服务器的性能，您通常会使用少量的响应式线程，因此阻塞也会很快导致死锁。
  • 没有互斥锁，因为它们可以阻塞，所以没有共享的可变状态。如果您需要共享状态，则必须将其包装为参与者或类似对象，以便只有一个线程可以访问该状态。
• 响应式(Reactive)线程中的所有工作都应受 CPU 限制
  • 所有 IO 都必须是异步的，或者在不同的线程池中执行，并将结果反馈到 react 器中。
  • 这意味着使用 future 或回调来处理回复，如果您不习惯并且不遵守纪律，这种风格的代码很快就会变得无法维护。
• react 线程中的所有工作都应该很小
  • 为了保持服务器的响应能力， react 器中的所有任务都必须很小(受时间限制)
  • 在 8 核机器上，您不能允许 8 个长任务同时到达，因为在它们完成之前不会开始其他工作
  • 如果一项任务可能需要很长时间，则必须将其拆分(协作式多任务处理)

响应式(Reactive)应用程序中的任务是由应用程序而不是操作系统安排的，这就是为什么它们可以更快并使用更少的内存。当您编写响应式应用程序时，您是在说您非常了解问题域，因此您可以更好地组织和安排此类工作，而不是操作系统可以以阻塞方式安排执行相同工作的线程。

我是响应式架构的忠实粉丝，但它们会带来成本。我不确定我是否会将我的第一个 c++ 应用程序编写为响应式，我通常尝试一次学习一件事。

如果您决定使用响应式架构，请使用一个可以帮助您设计和构建代码的良好框架，否则您最终会遇到意大利面。要寻找的东西是:

• 工作单位是什么？
• 添加新作品有多容易？它只能来自外部事件(例如网络请求)吗？
• 将工作分解成更小的 block 有多容易？
• 处理这项工作的结果有多容易？
• 将阻塞代码移动到另一个线程池并仍然处理结果有多容易？

我不能为此推荐 C++ 库，我现在在 Scala 中进行服务器开发和 Akka它为所有这些提供了一个出色的可组合 future 库，以保持代码干净。

祝你好运学习 C++ 以及你做出的任何选择。