Google App Engine - 任務隊列與Cron Jobs

Question

最新的Google App Engine版本支持Python中的新Task Queue API。我正在比較此API的功能與現有的Cron service。對於非用戶啓動的後臺作業，例如抓取RSS提要並按日間隔解析它。可以並且應該將Task Queue API用於非用戶發起的請求，例如這種情況嗎？

Answer 1

我會說「排序」。關於任務隊列要記住的事情是：

1）每分鐘/小時/天的操作限制與定期重複某些操作的限制不同。即使將令牌桶大小設置爲1，我也不認爲您可以保證這些重複會均勻分佈。這取決於他們認爲隊列實現爲令牌桶時的嚴重程度，以及該語句是否應該是界面的保證部分。這是實驗室，沒有任何保證。

2）如果一個任務失敗，那麼它被重新排序。如果一個cron作業失敗，那麼它會被記錄並且不會重試，直到它再次到期。因此，cron作業的行爲方式與添加自身副本然後刷新Feed的任務不同，或者作爲刷新Feed的任務，然後添加自己的副本。

使用任務模擬cron作業很可能是可能的，但我懷疑它是值得的。如果你正在努力解決一個需要30秒以上運行的cron作業（或者其他請求限制），那麼你可以將作品分成幾部分，並且有一個cron作業，將所有作品添加到任務隊列。有一些關於異步urlfetch的討論（在GAE博客中），這可能是更新RSS源的最佳方式。

Answer 2

我看待它的方式是，如果我只是解析一個RSS源，Cron作業可能就足夠好了。如果我必須解析用戶或任何其他系統變量在運行時指定的X個RSS源，那麼我將每次選擇任務。

我只是這樣說，因爲在過去，我不得不定期執行許多用戶定義的twitter搜索和Cron作業。我結束了一個非常糟糕的排隊系統來執行需要運行的請求 - 它沒有執行任何操作，噸的規模，它沒有幫助，而且一個cron工作的最小間隔只有1分鐘（我在一天中的搜索時間比分鐘多）。

關於任務的很酷的事情是你可以給他們一個ETA，所以你可以說我希望將來會執行47秒，或者我希望在12:30執行。

Answer 3

直到我看到Google I/O視頻才解釋它，我才明白它們之間的差異。官方來源通常是最好的。

youtube video

slides from the presentation