我正在考虑将AWS IoT用于一个应用程序，其中有数千个小位图显示（与专有无线协议连接）后面（可能是数百个）分布式网关（PC或Raspberry Pi）。
到目前为止，我提出了以下概念：
网关PC终止MQTT会话。它没有自己的设备表。
thingname = <gatewayId>_<displayId>
显示位图存储在S3（filename = thingname）
更新显示只是替换S3文件，然后在设备阴影所需的状态下更新位图版本（例如SHA）。
网关必须订阅/update/<gatewayId>/#
将有一条规则从/update/<gatewayId>_<displayId>重新发布到/update/<gatewayId>/<displayId>（因为在MQTT中，事物名称不能包含斜杠和通配符必须是完整的路径组件）
对于每个收到的消息，网关将从S3下载位图，将其发送到显示器，然后将报告的状态更新为新版本。
如何处理重新联机的断开网关？
订阅不是持久性的，所以我需要找到所有东西（来自那个网关），所需状态！=报告状态并再次更新它们。
可以有规则吗？我们的想法是让网关在重新联机时发布重新连接消息（如/reconnect/<gatewayId>）。该规则必须找到该网关的所有设备阴影，其中所需状态！=报告状态并发布它们。
NB：我知道我可以使用自己的数据库编写没有设备阴影的机制。但想法是使用物联网机制。
另一个问题： 创建位图非常快（可能是每秒1000个），发送到显示器可能非常慢（特别是发送一堆的第一个位图可能需要一分钟）。因此，在确认第一条消息之前，可能会创建数千个位图（对于一个网关）。这是一个问题吗？
答案 0 :(得分：3)
如果我正确理解您的用例，我认为您的概念可能需要进行一些更改才能使其更好地运行。我会尝试回答你的问题，将它们分成更小的部分。
状态同步：由于您的显示器与AWS IoT没有直接通信，因此如果您将网关视为things并将每个显示视为属性（例如，相应网关<display_id>的{{1}}}。这样，每当必须将新图像上传到显示器时，您只需将thing的{{1}}更新为相应的显示属性（例如desired state嵌套到{{1} }}）。您可以使用<bitmap_version> <display_id>主题（例如thing shadow）来执行此操作。您可以使用Lambda触发UPDATE主题的消息，以检测何时将新版本的显示位图上传到S3。
图片下载：每当新版本的位图上传到S3时，网关都会通过以下方式接收新版$aws/things/<gateway_id>/shadow/update以显示属性的特定位图版本UPDATE的{{1}}主题（例如desired state），下载新的位图，通过您的专有无线协议更新显示，并更新thing上ACCEPTED UPDATE的属性$aws/things/<gateway_id>/shadow/update/accepted 1}} reported state主题。
处理已断开连接的网关：是的，订阅不是永久性的，但如果您将网关视为thing shadow并且每个显示都是UPDATE的属性，每当它重新联机时，它都可以向things主题发布消息（例如thing），检查GET主题上$aws/things/<gateway_id>/shadow/get的当前状态（{{1}然后在新版本的情况下继续下载新的位图。
处理大数据量：如果您需要每秒更新网关的每个显示器，并且每个网关都有数千个显示器，我认为您可能会遇到问题遇到的是带宽瓶颈，并将所有这些MQTT消息与您的thing主题同步。如果您只需要偶尔更新一次显示，我认为您的概念可以很好地运作。
需要考虑的一些事项：
AWS IoT MQTT实施无法保证nested attribute。如果您需要按特定顺序接收消息，则必须在应用程序中实现该消息。
AWS IoT仍为order in which messages are received，因此许多实施细节可能会发生变化。