c++ - TNonblockingServer、TThreadedServer 和 TThreadPoolServer，哪一个最适合我的情况？

Question

我们的分析服务器是用 C++ 编写的。它基本上查询底层存储引擎并通过thrift返回相当大的结构化数据。一个典型的请求大约需要 0.05 到 0.6 秒才能完成，具体取决于请求的大小。

我注意到我们可以在 c++ 代码中使用的 Thrift 服务器有几个选项，特别是 TNonblockingServer、TThreadedServer 和 TThreadPoolServer。似乎 TNonblockingServer 是要走的路，因为它可以支持更多的并发请求，并且仍然在后台使用线程池来处理任务。它还避免了构建/销毁线程的成本。

Facebook 关于 Thrift 的更新:http://www.facebook.com/note.php?note_id=16787213919

Here at Facebook, we're working on a fully asynchronous client and server for C++. This server uses event-driven I/O like the current TNonblockingServer, but its interface to the application code is all based on asynchronous callbacks. This will allow us to write servers that can service thousands of simultaneous requests (each of which requires making calls to other Thrift or Memcache servers) with only a few threads.

stackover 上的相关帖子:Large number of simulteneous connections in thrift

That being said, you won't necessarily be able to actually do work faster (handlers still execute in a thread pool), but more clients will be able to connect to you at once.

只是想知道我在这里还缺少其他因素吗？我该如何决定哪一个最适合我的需求？

Answer 1

需要 50-600 毫秒才能完成的请求相当长。创建或销毁线程所需的时间远少于此，因此此时不要让该因素影响您的决定。我会选择最容易支持且最不容易出错的那个。您希望最大限度地减少细微并发错误的可能性。

这就是为什么编写单线程事务处理代码在需要的地方阻塞并让其中许多代码并行运行比编写更复杂的非阻塞模型更容易的原因。阻塞的线程可能会减慢单个事务，但它不会阻止服务器在等待时执行其他工作。

如果您的事务负载增加(即更多的客户端事务)或请求的处理速度变得更快(每个事务接近 1 毫秒)，那么事务开销就会成为一个更大的因素。要注意的指标是吞吐量:每单位时间完成多少事务。单个事务的绝对持续时间不如它们完成的速度重要，至少如果它保持在 1 秒以下。