高效地使用线程处理消息？

Question

我需要帮助设计一个消息分发系统。到目前为止，我有 2 个进程，一个监听远程客户端的传递消息，然后 写入数据库表。

然后我有第二个进程每隔 [n] 秒从同一个表中读取一次，一次读取最多可获取 100 条消息，如果有任何新记录，则将每条记录排队以在其自己的 ThreadPool 发出的 backgorund 线程上发送.

如果可用的消息多于线程，线程池会将所有超出其最大线程数的消息排队。如果没有消息，则返回睡眠状态并等待下一个 Timer 事件将其唤醒以再次检查 db 表。

问题是我可能在一个时间间隔内有很多消息到达：最好将它们留在 Db 中直到需要，而不是留在内存中，在 ThreadPool 中排队等待。

换句话说，我正在寻找一种优雅的方式来知道何时可以添加更多排队的线程，而不是简单地等到下一个计时器间隔......

我的一个想法是计算我排队的 Worker 线程数（例如：500，等于我首先设置的最大线程数），并在它们完成时计算它们。如果它们低于 1/2（例如：250），则重新进行 Db 检查。如果找到记录，很好，一次获取 100 个，直到完全读取 db 表，或者再次达到 500 个最大值。

换句话说，使出队的主要焦点是线程本身，自我启动自身的连续性，而不是计时器（计时器间隔只是因为在管道干涸的情况下重新启动进程的机制）。

有人对这样的系统有建议/cmets/经验吗？方法可靠吗？还是有严重缺陷？

Answer 1

我发现线程涉及的开销（例如上下文切换）会很快使使用线程对性能产生不利影响。此外，除非您的线程花费大量时间等待 IO 等，否则拥有比 CPU（或内核）更多的线程没有任何意义。

所以假设您确实需要线程来处理您的数据，也许您可​​以创建一些线程。每个线程查询数据库以获取一大块数据（一次可能限制为 100 行）并对其进行处理。当它完成处理时，它会尝试获取另一块数据。您将需要同步数据访问（即同步检索到的最后一行 ID），并且仍然需要一个计时器，以防线程处理所有可用数据并休眠。这种方法假定数据处理时间比数据库访问时间长得多。

最重要的是，你确定你真的需要线程吗？我会说你最好的选择是让它在没有线程的情况下工作，然后在必要时进行优化。这是我从线程中学到的最重要的一课（艰难的方式）。