【发布时间】：2022-07-05 13:38:57
【问题描述】：
所以我对使用 AWS IoT Core、AWS 规则引擎和 AWS DynamoDB 创建的 IoT 解决方案有疑问。
解决方案如下所示：MQTT 消息发布到主题“topic/+/data”，其中 “+”是发布消息的东西。有一个规则可以拦截这些消息 并且应该将发布的消息保存为 DynamoDB 表中的记录。问题是 并非所有消息都保存在数据库中。 DynamoDB 表容量模式设置为“按需”。
可能出错的地方：
- 并非所有消息都发布到主题流
- 该规则未捕获所有消息
- DynamoDB 未按应有的方式保留所有消息
可以消除 1 和 2，因为 AWS Cloudwatch IoT 日志仅显示成功的“RuleExecution”事件，这些事件对应于发布的消息数量，即如果发布了 600 条消息 然后有 600 个成功的“RuleExecution”事件。这也针对已发布的 500 条消息进行了测试。这些消息源自 Apache JMeter 的负载测试，其中模拟了不同数量的设备每秒发布一条消息。设备数量从 10 到 100 不等，运行时间在 30 秒到 15 分钟之间。所有测试的结果都占很大比例，高达 30% 未插入到 DynamoDB 表中的消息，即使 Cloudwatch 声称它们是成功插入。
不知何故，DynamoDB 不会插入所有被规则拦截的消息，即使 Cloudwatch 确认所有“RuleExecution”事件均成功。 Cloudwatch 也不显示任何失败的事件。
这可能是什么原因？
【问题讨论】：
-
您如何确定并非所有项目都进入了 DynamoDB？是否有可能多个项目具有相同的键（因此一个会覆盖前一个项目）？
-
@jarmod 创建解决方案时，这完全超出了我的想象。这听起来很可能是一个原因，因为用于每个表条目的主键是 unix 时间戳。每秒有 100 个排队的条目，有些可能最终拥有相同的密钥。由于 AWS IoT 规则中的 timestamp() 函数以毫秒为单位运行，因此一旦每秒插入次数增加，可能会有一些覆盖。但是，当每秒有 100 条消息发布到主题流时，覆盖率 30% 似乎不太可能。虽然我很欣赏这个想法。
-
您可以在代码中或通过 CloudTrail 显式计算放入 DynamoDB 的次数，然后与表中的项目数进行比较。这将迅速提醒您重复键。或者您可以修改您的 put 以使其以不存在该键的项目为条件，方法是使用 condition 并引发可见错误。
-
虽然，由于消息来自同时运行所有线程的 JMeter 脚本，并且每个线程都有 1 秒的延迟来发帖，这意味着所有线程都尝试同时发帖时间，这可能是原因。
-
如果可行，您可以在密钥上附加一个短 UUID 后缀。
标签： amazon-web-services amazon-dynamodb amazon-cloudwatch rules aws-iot-core