我正在尝试将一个大型的Scala + Akka + PlayMini应用程序与外部REST API进行接口连接。思路是定期轮询(基本上每1到10分钟)根URL,然后浏览子级URL以提取数据,然后发送到消息队列。
我想出了两种方法来实现这个:
第一种方法
创建一个Actor层次结构来匹配API的资源路径结构。在Google Latitude的情况下,例如:
- Actor 'latitude/v1/currentLocation' 轮询 https://www.googleapis.com/latitude/v1/currentLocation
- Actor 'latitude/v1/location' 轮询 https://www.googleapis.com/latitude/v1/location
- Actor 'latitude/v1/location/1' 轮询 https://www.googleapis.com/latitude/v1/location/1
- Actor 'latitude/v1/location/2' 轮询 https://www.googleapis.com/latitude/v1/location/2
- Actor 'latitude/v1/location/3' 轮询 https://www.googleapis.com/latitude/v1/location/3
- 等等。
在这种情况下,每个Actor负责定期轮询其关联的资源,并为下一级路径资源创建/删除子Actor(即,actor 'latitude/v1/location'通过轮询https://www.googleapis.com/latitude/v1/location学习到所有位置后,创建1、2、3等Actor)。
第二种方法
创建一个池,其中包含相同的轮询Actor,这些Actor接收包含资源路径的轮询请求(由路由器负责负载均衡),对URL进行一次轮询,执行一些处理,并安排轮询请求(用于下一级资源和已轮询的URL)。在Google Latitude中,例如:1个路由器,n个轮询者Actor。针对https://www.googleapis.com/latitude/v1/location的初始轮询请求会导致多个新的(即时)轮询请求,如https://www.googleapis.com/latitude/v1/location/1、https://www.googleapis.com/latitude/v1/location/2等,以及一个(延迟的)轮询请求,即https://www.googleapis.com/latitude/v1/location。
我已经实现了这两种解决方案,暂时无法观察到任何重要的性能差异,至少对于我感兴趣的API和轮询频率来说是如此。我发现第一种方法在某种程度上更容易理解,可能比第二种方法更容易使用system.scheduler.schedule(...),而第二种方法(我需要使用scheduleOnce(...))则更易于编写。此外,假定资源通过几个级别进行嵌套并且生命周期较短(例如,在每次轮询之间可能会添加/删除多个资源),Akka的生命周期管理使得在第一种情况下轻松地消除整个分支。第二种方法应该(理论上)更快,代码写起来也相对容易。
我的问题是:
- 哪种方法似乎是最好的(就性能、可扩展性和代码复杂性而言)?
- 您是否认为任何一种方法的设计存在问题(尤其是第一种方法)?
- 有人试图实现过类似的功能吗?如何实现的?
谢谢!