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

Question

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

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

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

问题是在一个时间间隔内我可能会收到很多消息:将它们留在 Db 中直到需要时而不是在内存中在 ThreadPool 中排队等候要好得多。

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

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

换句话说，使出列的主要焦点成为线程本身， self 启动它们自己的连续性，而不是计时器(计时器间隔只是因为一种机制，可以在管道干涸的情况下重新启动进程)。

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

Answer 1

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

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

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