一千萬個為什麽

搜索

使用隊列或應用程序級別執行延遲作業會更好嗎?



我正在嘗試擴展推送通知基礎結構。我們目前使用在負載均衡器後面水平縮放的2個ec2實例上運行的laravel應用程序,並且每個實例都有一個beanstalk隊列引擎,用於處理由laravel(包括推送通知作業)創建的作業。

問題是這個解決方案不是高性能的。有時候,我們會向所有客戶發送營銷推廣信息......數量為數千,而第一推送通知和最後一個推送通知之間的時間差異可能需要數小時。

我正在考慮哪些基礎設施是很好的選擇。我考慮過AWS SQS,但事實證明,它的最大延遲工作能力是15分鐘。在我的生意中,顧客可以在20小時前預訂。因此,我們目前所做的是計劃從現在起20小時的延遲工作。

但是有些人認為延遲部分應該只發生在應用程序級別(即 delay(work,timedelta(hours = 20))),這樣我就可以使用SQS。他們的推理是推遲工作是一種商業邏輯,最好在應用程序級別而不是基礎設施級別進行處理。

我不確定我是否同意..這就是為什麽我使用redis選擇AWS彈性緩存。你們有什麽感想?

轉載註明原文: 使用隊列或應用程序級別執行延遲作業會更好嗎?

一共有 2 個回答:

這聽起來有輿論依據,但我認為有一個重要的事情足以縮小問題的答案。

這仍然是一種觀點,但是,就水平縮放而言,實例可能會隨意出現和消失,因此,保持內存延遲不是一種選擇,因此此時您必須解決此問題並烘焙一些類似一個通知隊列/表,用於保留在哪個時間發送的內容,並定期檢查要發送的內容。

一旦這麽說,你需要一個中心位置來將所需的通知從應用程序實例本身中保存下來,因此您需要一個地方來存儲它們,它可以是一個redis服務,一個數據庫表或其他,無論如何你都會編碼。

在AWS上工作時,所提供的服務已經是多余的並且在高可用性的情況下不需要太多的努力,因此我會使用存儲通知的應用程序代碼隨時發送它,並定期進行lambda檢查,通知哪些通知必須發送通知,然後可以通過SQS發送通知,以便在發送失敗的情況下利用重試,或者您必須在通知發射系統中處理通知。

在我看來,商店部分是彈性緩存或其他東西是一個品味和團隊知識的問題,采取任何你更舒適的方式。
對於觸發通知的部分,我會使用與應用程序本身分離的內容,另一個應用程序或Lambda定期檢查“緩存”(DB或Redis或其他)以發送通知。

這使得應用程序可以確保緩存中聲明和確認的通知已正確註冊,並且在需要時將被觸發,並在出現問題時重新嘗試。最後一種情況是不可能發送通知,您可能需要在應用程序中跟蹤這些信息,以避免發送過多的通知,並以無效的方式結束,但這個問題已經超出了範圍。

我建議使用調度程序來安排作業執行,而不是構建延遲執行的邏輯。調度程序為您提供狀態更新的附加優勢。考慮使用AWS的簡單工作流服務。

您可以使用Lambda來處理您的營銷工作,而不是使用豆莖隊列引擎?簡單工作流程服務適用於Lambda。您不必擔心使用Lambda進行縮放。