轮询有什么问题？

Question

40

最近我听到一些开发人员说，他们只是轮询数据库、文件等来确定何时发生了更改，然后运行任务（例如导入）。

我非常反对这种想法，认为利用可用技术例如远程调用、WCF等比轮询更好。

然而，我想找出其他人喜欢一种方法胜过另一种的原因，更重要的是，如何说服其他人在现代社会中放弃轮询的方式？

- HAdes

FYI：Remoting和WCF进行轮询。 - Timothy Khouri

在某种程度上是的，但不是像一些开发人员明确使用轮询的方式，即每分钟轮询一次数据库。 - HAdes

我有一个类似的情况，需要在多个ftp位置上进行多次轮询以获取更新的文件，应该采取什么最优方式来处理这种情况？ - Rachel

除了“因为它更容易”，另一个常见的需要进行轮询的原因是被轮询的对象无法更改为推送通知（可能是因为它不在您的控制范围内；更改它的成本或风险被认为太高等）。 - TripeHound

我完全同意你的观点，这是错误的，它毫无意义地占用了资源。人们这样做的原因是因为这是最简单的选择。 - MarcusJ

18个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Ismael C · Answer 1

我看到这里有很多答案，但我认为最简单的答案就是回答本身：

因为编写轮询循环通常比创建回调基础设施更加简单。

然后，您可以获得更简单的代码，如果它后来成为瓶颈，可以轻松理解并重新设计/重构为其他东西。

- Ali A · Answer 2

这并不是回答你的问题。但是实际上，尤其是在目前这个“时代”，处理器周期廉价而带宽大的情况下，轮询实际上是某些任务的一个相当好的解决方案。

其优点包括：

- 廉价 - 可靠 - 可测试 - 灵活

- kronoz · Answer 3

我同意避免轮询是一个好的策略。然而，关于Robert's post，我认为在这些问题不是很严重的情况下，轮询的简单性可以使其成为更好的方法，因为异步方法通常较难阅读和维护，更不用说可能会出现的实现错误。

- Valerion · Answer 4

就像所有事情一样，这取决于具体情况。我目前正在处理的一个大型高交易系统使用了一个带有SQL通知的方法（在某些表的触发器中调用扩展存储过程的DLL被加载到SQL Server中，然后该DLL通知其他应用程序有工作要做）。

然而，我们正在逐渐摆脱这种方法，因为我们可以几乎保证会不断有工作需要处理。因此，为了降低复杂性并稍微加快速度，应用程序将处理它们的工作并立即再次轮询数据库以获取新的工作。如果没有新工作，它将在短时间间隔后再次尝试。

这似乎更快且更简单。然而，应用程序的另一部分，交易量较低，使用这种方法并没有提高速度 - 除非轮询间隔非常小，这会导致性能问题。因此，对于这部分，我们将其保持原样。因此，当适用时，这是一件好事，但每个人的需求都不同。

- DubMan · Answer 5

当考虑SQL轮询时，在VB6时代，您可以使用WithEvents关键字创建记录集，这是异步“监听”的早期版本。

我个人总是会寻找一种事件驱动的实现方式，而不是轮询。如果失败，以下任何一种手动实现可能会有所帮助：

其中一些可能需要对项目进行轻微重新设计，但在企业世界中，这可能是比轮询服务更好的路线。

- Andrew Grothe · Answer 6

大多数回答都认为异步/消息传递通常更好，我完全同意Robert Gould的答案。但我想再补充一点。

其中一个优点是轮询可以一举两得。在一个特定的用例中，我参与的一个项目在数据库之间使用了消息队列，但从应用服务器到其中一个数据库进行轮询。由于应用程序服务器到数据库的网络偶尔会出现问题，因此还使用了轮询来通知应用程序网络问题。

最终，根据可扩展性考虑，使用对该用例最有意义的方法。

- ottodidakt · Answer 7

我希望我能够进一步概括这个答案，但有些事情最好不要删减。

- Mike · Answer 8

我正在使用轮询来检查文件更新，因为我需要在不同操作系统类型的异构系统中获取有关该文件的信息，其中一个非常古老。如果文件位于具有不同操作系统的远程系统上，则 Linux 的通知将无法工作，因为该信息未传输，但轮询可以正常工作。这是一种低带宽检查，因此不会对任何事情造成影响。