AWS 簡單佇列服務(SQS) 提供可靠且可擴充的訊息傳遞解決方案，而AWS Lambda 則提供無伺服器運算功能。將這兩種服務結合起來可以實現強大的事件驅動架構。在這篇文章中，我們將深入探討SQS 和Lambda 之間的集成，了解訊息消費和處理背後的機制。我們將深入研究單獨或批次處理訊息的可用選項，重點介紹每種方法的優點和注意事項。此外，我們將討論Lambda 事件來源對映和SQS 的值得注意的配置，例如批次大小、批次視窗、最大並發性和佇列可見性逾時。我們Oncloud AI透過本文幫助您了解SQS 和Lambda 整合的強大功能。
了解SQS 和Lambda 集成
SQS 和Lambda 提供了強大的集成，可用於建立可擴展且事件驅動的架構。借助Lambda 事件來源映射，您可以非同步處理來自SQS 佇列的訊息，從而解耦元件並確保可靠的訊息傳遞。當Lambda 函數訂閱SQS 佇列時，它會使用輪詢機制等待訊息到達。 Lambda 以批次處理訊息。對於每個批次，Lambda 都會觸發一次函數。如果隊列中有更多消息，Lambda 可以擴展到1,000 個並發函數，每分鐘最多可添加60 個函數。成功處理後，Lambda 會自動從佇列中刪除訊息。
使用Lambda 使用SQS 的訊息
使用SQS 時，您可以單獨或批次處理訊息。 Lambda 事件來源對映支援更大的批次，標準SQS 佇列的單一批次最多可容納10,000 則訊息或6 MB。相較之下，SDK 限制每個API 呼叫最多可容納10 則訊息。這就是為什麼您在使用來自SQS 的訊息時應盡可能使用Lambda 事件來源對應的原因之一。
單獨處理訊息具有處理速度更快、錯誤處理更簡單的優勢。但是，在某些情況下，批次處理更合適。當您需要更高的吞吐量、更高的效率或成本最佳化很重要時，批次是有益的。
處理單一訊息
在Lambda 中使用單一SQS 訊息相對簡單，每個訊息都被視為觸發Lambda 函數執行的獨立事件。實施適當的錯誤處理以捕獲在訊息處理過程中可能發生的任何異常或錯誤仍然很重要。當Lambda 函數成功處理訊息時，Lambda 將自動從佇列中刪除該訊息。但是，如果在函數執行過程中捕獲到錯誤，則該訊息將返回到佇列以進行進一步處理或重試。這可確保在發生錯誤時不會遺失訊息，並允許正確處理和重新處理失敗的訊息。
處理大量訊息
當Lambda 處理來自SQS 佇列的一批訊息時，這些訊息會保留在佇列中，但會根據佇列的可見性逾時暫時隱藏（本篇部落格文章後面會詳細介紹）。如果您的Lambda 函數成功處理了該批次訊息，Lambda 會自動從佇列中刪除這些訊息。但是，如果您的函數在處理批次訊息時遇到錯誤，則該批次訊息中的所有訊息都會重新出現在佇列中，使它們再次可見。
為了確保訊息不會被多次處理，您有幾個選擇。首先，您可以設定事件來源映射以包含ReportBatchItemFailures在函數響應中。這允許您在函數程式碼中處理和追蹤失敗的訊息，這是處理批次時的建議方法。或者，您可以使用名為DeleteMessage 的Amazon SQS API 操作在Lambda 函數成功處理訊息時明確從佇列中刪除訊息。使用此API 操作可確保不會無意中重新處理訊息。
我將提供兩個範例，說明如何利用ReportBatchItemFailures 功能傳回部分失敗的訊息，這將確保我們的函數不會多次處理訊息。我將透過建立batchItemFailures 函數回應以及使用Middy中間件來示範如何做到這一點。
值得注意的配置
Lambda 事件來源映射
批次大小
批次大小 ( BatchSize) 配置決定了每個批次中傳送到Lambda 函數的記錄數。對於標準佇列，您可以將批次大小設定為最多10,000 筆記錄。但是，需要注意的是，無論配置了多少筆記錄，批次的總大小都不能超過6 MB。
批次視窗
批次視窗 ( MaximumBatchingWindowInSeconds) 設定確定在呼叫Lambda 函數之前收集記錄的最大時間（以秒為單位）。請注意，此配置僅適用於標準隊列。
最大並發數
最大並發 ( ScalingConfig) 功能使我們能夠為事件來源映射設定最大並發呼叫數，從而消除了先前在Lambda 中使用保留並發時出現的過度限制所導致的問題。借助此功能，我們可以更好地控制並發，尤其是在使用具有相同功能的多個事件來源映射時。
SQS 配置
佇列可見性逾時
SQS 中的可見性逾時 ( VisibilityTimeout) 是一種設置，用於確定訊息在被消費者檢索到後在佇列中保持不可見狀態的時間。當消費者從隊列收到一則訊息時，在可見性逾時期間，該訊息將暫時對其他消費者隱藏。如果您選擇的批次視窗大於0 秒，則必須考慮在佇列的可見性逾時內增加的處理時間。建議將可見性逾時設定為函數逾時的至少六倍，再加上批次視窗 ( MaximumBatchingWindowInSeconds) 的值。這可確保您的Lambda 函數有足夠的時間處理每一批事件並處理由限制錯誤導致的潛在重試。例如，如果您的函數逾時為30 秒，批次視窗為20 秒。這將設定為(30 x 6) + 20 = 200 秒。
死信佇列(DLQ)
當Lambda 無法處理某一訊息時，該訊息將會回到佇列進行重試。但是，為了防止該訊息多次新增至佇列並導致不必要的Lambda 資源消耗，建議指定死信佇列(DLQ) 並將失敗的訊息傳送到該佇列。若要控制失敗訊息的重試次數，您可以設定Maximum receivesDLQ 的值。一旦某則訊息重新加入到佇列的次數超過最大接收次數，它將被移至DLQ。這樣您就可以稍後處理這些失敗的訊息，而不必在主佇列中處理。
結論
總之，SQS 與Lambda 之間的集合成為建構事件驅動架構提供了強大且可擴展的解決方案。透過利用事件來源映射、配置批次以及利用死信佇列和可見性逾時等值得注意的功能，您可以確保可靠的訊息處理並優化資源利用率。採用這種整合可以充分發揮分散式系統的潛力，並創建可輕鬆擴展的彈性應用程式。
Oncloud AI身為AWS代理商，提供亞馬遜雲端服務，支援亞馬遜雲端伺服器AWS代付、AWS遷移、AWS維運託管等服務，如有相關需求可聯繫Oncloud AI。
