我听说有一些开发人员最近说他们只是轮询东西(数据库,文件等)以确定什么时候发生了变化,然后运行任务,比如导入.
我真的反对这个想法,并认为利用Remoting,WCF等可用技术将远远优于民意调查.
但是,我想确定为什么其他人更喜欢一种方法而不是另一种方法的原因,更重要的是,我怎样才能说服其他人在当今这个时代投票是错误的呢？
轮询并非"错误".
很大程度上取决于它的实现方式和目的.如果您真的关心即时通知变更,那么效率非常高.您的代码处于紧密循环中,不断轮询(询问)资源是否已更改/更新.这意味着只要您有所不同,就会立即通知您.但是,您的代码没有做任何其他事情,并且在对相关对象的许多调用方面存在开销.
如果您不太关心立即通知,可以增加轮询之间的间隔,这也可以很好地工作,但选择正确的间隔可能很困难.太长了,你可能会错过关键的变化,太短暂而你又回到了第一种方法的问题.
替代方案,例如中断或消息等,可以在这些情况下提供更好的折衷.您会在实际可能的情况下尽快通知您,但这种延迟不是您控制的,它取决于组件本身是否及时传递状态变化.
民意调查的"错误"是什么？
它可以是资源占用.
这可能是限制性的(特别是如果你想知道很多关于/民意调查的事情).
这可能是矫枉过正的.
但...
它本身并不是错误的.
它可能非常有效.
这很简单.
在这个时代使用民意调查的事例:
电子邮件客户端轮询新邮件(即使使用IMAP).
RSS阅读器轮询订阅源的更改.
搜索引擎轮询其索引页面的更改.
StackOverflow用户通过点击'刷新'来查询新问题;-)
Bittorrent客户轮询跟踪器(我认为,与DHT一起)对群中的变化进行轮询.
多核系统上的自旋锁可以是核之间最有效的同步,如果延迟太短,以至于没有时间在该核上安排另一个线程,而另一个核执行我们正在等待的任何内核.
有时候根本没有任何方法可以获得异步通知:例如,用推送系统替换RSS,服务器必须知道读取订阅源并有办法联系它们的每个人.这是一个邮件列表 - 正是RSS旨在避免的事情之一.因此,我的大多数示例都是网络应用程序,这很可能是一个问题.
其他时候,即使存在异步通知,轮询也足够便宜.
对于本地文件,原则上更改通知可能是更好的选择.例如,你可能(可能)阻止磁盘停止,如果你永远戳它,虽然然后操作系统可能会缓存.如果你在一个每小时只改变一次的文件上每秒轮询一次,你可能会不必要地占用你机器处理能力的0.001%(或其他).这听起来很小,但是当您需要轮询100,000个文件时会发生什么？
但实际上,无论你做什么,开销都可以忽略不计,这使得很难对改变当前有效的代码感到兴奋.最好的办法是注意轮询导致你想要改变的系统的特定问题 - 如果你发现任何问题然后提出这些问题而不是试图对所有轮询进行一般性论证.如果你没有找到任何,那么你无法解决没有破坏的问题......
原则上,为什么民意调查可能被视为不良,这有两个原因.
这是浪费资源.在没有发生任何变化的情况下,您很可能会检查更改.此操作的CPU周期/带宽花费不会导致更改,因此可能更好地花费在其他内容上.
轮询在一定时间间隔内完成.这意味着在下一次间隔过去之前,您不会知道发生了更改.
最好收到变更通知.这样,您就不会轮询尚未发生的更改,并且只要收到通知就会知道更改.
轮询很容易做到,非常简单,就像任何程序代码一样简单.不进行轮询意味着你进入了异步编程的世界,这种情况并不像脑子一样简单,有时甚至可能变得具有挑战性.
和任何系统中的所有内容一样,通常更常采用阻力较小的路径,因此总会有程序员使用轮询,甚至是优秀的程序员,因为有时不需要使用异步模式使事情复杂化.
我总是茁壮成长,以避免轮询,但有时候我会进行轮询,特别是当异步处理的实际收益不是那么好时,例如当对一些小的本地数据采取行动时(当然你会更快一点,但用户我不会注意到这种情况的差异).所以这两种方法都有恕我直言的空间.
客户端轮询不像服务器通知那样扩展.想象一下,成千上万的客户向服务器询问"任何新数据？" 每5秒钟.现在假设服务器保留一个客户列表来通知新数据.服务器通知更好地扩展
我认为人们应该意识到,在大多数情况下,即使在事件或中断驱动的情况下,也会在某种程度上进行轮询,但是您与执行轮询的实际代码隔离开来.真的,这是最理想的情况......将自己与实施区分开来,只是处理事件.即使您必须自己实现轮询,也要编写代码以使其孤立,并且结果将独立于实现进行处理.
京公网安备 11010802040832号 | 京ICP备19059560号-6 