我在嵌入式设备上使用 IoTHub 设备客户端 SDK。该应用程序将定期向物联网中心发送遥测消息。物联网设备连接无线路由器，通过WAN口无线连接互联网。
当无线路由器失去互联网连接时，物联网设备不会立即收到有关断开连接的通知。大约需要 60 秒才能收到通知，然后物联网设备将继续使用 IoTHubDeviceClient_LL_SendEventAsync() 发送遥测消息，所有这些消息都会在 SDK 层中排队并消耗内存。由于它位于资源有限的嵌入式设备上，因此内存会被耗尽并导致程序被较低内存 killer 应用程序杀死。
有没有办法指定总大小的物联网消息可以在sdk层排队？如果超过此配额，IoTHubDeviceClient_LL_SendEventAsync() 将立即失败。
其实正常场景也是需要的。当物联网设备发送消息时，消息似乎在低层排队并在某个时间被刷新。我没有看到任何可以控制刷新的 API。这就产生了另一个问题，即使有互联网连接，从应用程序级别来看，也无法控制排队的消息数量和排队时间，反过来，应用程序也无法控制进程使用了多少内存。在我的设备上，有一个系统监视器会杀死使用过多内存的进程。
最佳答案
问题是如果队列已满的情况下出现消息失败怎么办？那么您是否会因为存储容量不足而丢失信息？从物联网的角度来看，在这种情况下，我建议考虑您的设备是否是可靠的物联网设备，可以处理这些边缘情况。了解设备的限制，以及了解没有互联网连接可以持续多长时间，有助于减轻应用程序(而不是 SDK)带来的这些风险。
来自 GitHub，默认的 sendMessageAsync 方法会在消息发送失败时抛出超时异常，除非您实现了某种重试策略(根据文档 C SDK 不允许自定义重试策略) https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-reliability-features-in-sdks )。
根据文档，如果基于重试策略(如果您设置了重试策略)导致连接失败，SDK 将尝试以这种或那种方式启动连接，并同时对创建的消息进行排队: https://github.com/Azure/azure-iot-sdk-c/blob/master/doc/connection_and_messaging_reliability.md
因此，这里的期望是 SDK 不对内存限制负责。这取决于应用程序来处理。由于您的设备有一些限制，我建议您实现自己的排队机制(也许将不重试设置为策略，这样就可以避免排队)。这样，您就可以控制在没有互联网连接和内存限制的情况下会发生什么。也许您的业务案例接受您计算平均值，而不是 50，而是随着时间的推移存储 1 条消息等。
如果你不喜欢这个，文档还说你设置了队列的超时 - 也许不是内存限制，但超时是的，所以也许你可以尝试更深入地研究一下:
“该系统中有两个超时控制。一个是 iothub_client_ll 层中的原始超时控制 - 控制“等待发送”队列 - 另一个是协议(protocol)传输层中的现代超时控制 - 适用于“进行中”列表. 但是，由于 IoTHubClient_LL_DoWork 会导致 Telemetry 消息立即* 处理、发送并移动到“正在进行”列表，因此第一个超时控制实际上不适用。
用户可以通过 IoTHubClient_LL_SetOption 对两者进行微调，因此删除原始控件可能会导致现有客户中断。因此，它一直保持原样，但当我们转向该产品的下一个主要版本时，它将重新设计。”
关于azure-iot-hub - 限制飞行物联网消息的总大小，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55660069/