我需要帮助设计一个消息分发系统。到目前为止，我有两个进程，一个监听远程客户端传递消息，然后是 写入数据库表。
然后我有第二个进程，每隔[n]秒从同一个表中读取一次，在一次读取中最多可获得100条消息，如果有任何新记录，则每个进程都会在自己的ThreadPool发出的backgorund线程中发送
如果有多于线程的消息可用，则ThreadPool将排除超出其最大线程数的所有消息。如果没有消息，则返回休眠状态并等待下一个Timer事件将其唤醒，以便再次检查db表。
问题是我可以在一个时间间隔内收到很多消息：将它们留在Db中直到需要而不是在内存中排队，在ThreadPool中排队，等待会好得多。
换句话说，我正在寻找一种优雅的方式来了解何时知道可以添加更多排队的线程，而不是简单地等到下一个定时器间隔......
我有一个想法是计算我排队的工作线程数（例如：500，等于我先设置的最大线程数），并在完成时计算它们。如果它们低于1/2（例如：250），则重新进行Db检查。如果找到记录，很好，一次获得100，直到完全读取db表，或再次达到500 max。
换句话说，使出列的主要焦点是线程本身，自我启动自身连续性，而不是计时器（计时器间隔只是因为在管道干涸的情况下重新启动过程的机制）。 / p>
有没有人对这样的系统有建议/意见/经验？方法是否牢固？还是严重缺陷？
答案 0 :(得分：1)
我发现线程中涉及的开销（如上下文切换）可以快速使用对性能有害的线程。此外，除非您的线程花费大量时间等待IO等，否则拥有更多线程并不比拥有cpus（或核心）更重要。
因此，假设您确实需要线程来处理数据，也许您可以创建一些线程。每个线程查询数据库以获取一大块数据（可能一次限制为100行）并对其进行处理。完成处理后，它会尝试获取另一块数据。您将需要同步数据访问（即同步检索的最后一行ID），并且在线程处理所有可用数据和休眠时仍需要计时器。此方法假定数据处理所需的时间比数据库访问长得多。
最重要的是，你确定你真的需要线程吗？我会说你最好的选择是让它在没有线程的情况下运行，然后在必要时进行优化。这是我学到的关于线程的最重要的一课（艰难的方式）。