2008-07-28

轮询 vs. 事件

Evan Henshaw-Plath在OSCON2008做了题为“Beyond REST? Building Data Services with XMPP PubSub”的讲话,谈到RSS轮询检索导致的伸缩性问题。

Friendfeed网站使用RSS技术用来收集数据,就在2008年7月21日,为了得到45,754个用户最新图片信息,它就爬了2,975,981次,但其中仅有6,721的用户会上传图片。从这组数据看,平均对一个用户在一天里约查询65次,查看更新内容。假如用户习惯一天更新一次,对于这预计的一次更细,系统就要承担约443次(2975981/6721)的无效查询,压力增大443倍。更为糟糕的,RSS列表是有长度限制的,一般是20条,这意味着,如果用户上传了许多的话,系统记下的最多只能是20条。控制更新服务质量的方式,就是控制查询的频率和窗口大小(RSS清单项目最大数)。频繁的查询、大的查询窗口,对单个用户来说,更新的数据会更可靠,但对系统来说,系统的效用会更差。

问题的确严重,系统承担不必要的巨大压力,能源损耗也是巨大。为了这个问题,Henshaw-Plath讲话中提出了XMPP的消息传递的方法。是基于轮询(poll-based)?还是基于事件(event-based)?三四十年来,架构设计一直在这个问题上来回摇摆。

“轮询”,结构和实现方法是简单易上手,但以性能为代价;“事件”,效率的确好,但传递机制和维护措施复杂。一个事实是,无论是性能的代价,还是机制的复杂,它们都会导致系统伸缩问题。

没有评论: