在 AWS IoT 中，我可以創建一個規則來路由傳入的 mqtt 有效負載以供 lambda 處理。同樣，我可以撰寫一個 lambda 來將 mqtt 訊息發送到設備（傳出）。我的問題：
- 是否存在 IoT 核心出于任何原因永遠無法將傳入訊息移交給 lambda 的風險？
- 同樣，是否存在 lambda 永遠無法將傳出的 mqtt 訊息發送到設備的風險？
換句話說，我如何保證（或在架構上提出至少提高交付可靠性而又不會過火的解決方案）lambda 接收/發送 mqtt 訊息？這就是為什么要使用 SQS 的原因嗎？我們將要發送的傳出訊息作為 SQS 主題。Lambda 接收它并使用 mqtt 協議中的至少一次傳遞選項發送訊息。如果由于某種原因我沒有收到 ACK，我是否會從 SQS 回滾出隊或將其放入不同的“稍后處理”佇列（或 DLQ）？
uj5u.com熱心網友回復：
如果我們談論的是非超大規模 IoT 應用程式，AWS 在服務之間丟棄訊息不應該讓您夜不能寐。IoT 核心 -> Lambda 設定非常好。AWS 服務非常可靠。建筑之神不會因為您的選擇而對您不屑一顧。*
不過，在我們喊YAGNI回家之前，我們應該承認，正常大小的應用程式有充分的理由將訊息排隊（IoT Core -> SQS -> Lambda）。
SQS 佇列有很多花里胡哨的東西，但對于普通人來說可能不是必備品。相反，正常大小的 MVP 應用程式提前跳上 SQS 列車的情況可歸結為兩個原因：
- 錯誤處理的便利性： 讓我們面對現實吧，與 AWS 錯誤相比，我們可能更應該擔心自己的錯誤導致 lambda 錯誤。佇列為我們提供了暫停和重放功能，以防我們的 lambda 代碼失敗。錯誤顯示在 DLQ 中，而不是日志中。
- 便宜： SQS 不是腦外科手術，既不復雜也不昂貴。那為什么不呢？
* 如果您熱衷于擔心可靠性，備份和跨區域冗余可能是更好的投資選擇。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/351660.html