在同一進程中處理消息並將其發送到雲而不會丟失數據的好的設計是什么？

Question

我正在設計一種解決方案，用於將數據從基於 windows 的設備發送到雲端。

這里是高層

設備軟件：設備軟件目前以C或C++語言C# ，基於設備 model 和舊版本。

IoT 服務：這是一項提議的服務，可能作為windows service運行，這可能使用C#語言以及Azure SDK用於 IoT 中心連接。

現在的問題是，處理從Device Software到IoT Service的大量消息並在不丟失任何數據的情況下成功將它們發送到雲端的最有效方法是什么？ 我的意思是我是否必須使用任何有助於處理消息和重試邏輯的Queue概念或MQTT庫？

是否應該實施消費者來重試失敗的消息，或者Remote procedure call是否足以滿足此用例？

這是IoT時代的一個實時用例。

Answer 1

很想知道您發送消息的速率、設備數量和消息大小。 像大多數公共端點一樣，IoT 中心實施速率限制以減輕攻擊向量，您需要適當調整它的大小。 該鏈接提供了一些詳細信息。 https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-quotas-throttling 。 例如，1 個 IoT Hub S3 SKU 單元每秒可以處理總共 6000 個發送操作，您可以添加更多單元來增加它。

如果不需要立即分析和響應此類消息，您可以批處理並作為文件上傳，遙測和出錯時批處理的組合是有效的並且受 IoTHub 支持（文件被上傳到 IoTHub 中配置的 Blob 存儲）

關於第二個問題，IoTHub 有內部隊列和分區機制以高速攝取並以不同速率在后端消費，默認存儲最多 7 天。 如果您使用的是 SDK，它們會實現帶有后退的指數抖動來處理瞬態問題，但任何其他問題，例如身份驗證失敗或網絡中斷，您都需要在設備本身上構建存儲轉發。 IoT Hub 服務保證至少傳遞一次 (MQTT QoS 1)，因此您不會丟失消息，除非設備因中斷或程序/設備崩潰而無法重試未傳遞的消息。

如果設備能夠運行 IoT Edge，則運行時具有內置的存儲和轉發功能，但它不適合受限設備。

Answer 2

如果一定要避免在進程崩潰、OS重啟、斷電等情況下數據丟失，那么我看到的唯一解決方案是將數據持久化到磁盤，確認發送后清除。

在進程重新啟動的情況下，程序需要查看存儲數據的磁盤、提取數據並嘗試發送數據。 這意味着有可能發送重復數據（數據被持久化、遙測發送、進程在持久化數據被刪除之前退出），但是如果您為每條消息生成一個 GUID 並將其存儲在 MessageId 中，您可以檢測和重復數據刪除在服務端。