Lorawan-stack: 优化设备匹配

创建于 2020-06-05 · 5评论 · 资料来源: TheThingsNetwork/lorawan-stack

概括

优化网络服务器中的设备匹配

我们为什么需要这个？

当我们增加 DevAddr 重用和增加 DevAddr 大小时，对于 Redis I/O、内存使用和整体计算性能。

什么已经存在？你现在看到了什么？

目前，NS 通过 DevAddr 覆盖设备，并解码 proto。 protos 很大，包含 mac 状态和最近的上行链路和下行链路消息，而且可能有很多（数百个）重复 DevAddr 的 protos。

有什么不见了？你要看什么？

在加载匹配的设备之前，我们需要 Redis 中的物化视图，以便通过 UID 将上行链路与设备进行匹配。

您建议如何实施？

将匹配的相关信息存储在专用密钥中，因此基本上是 DevAddr、FCnt、NwkSIntKeys 和 UID。

排序集和/或哈希映射将非常有用，因为这可以通过 FCnt 启用 Redis 排序和查询，获取完整性密钥和 UID。

在每个上行链路和加入接受上更新此物化视图。

我们可以进行滚动迁移并回退到现有的匹配方案。

你打算如何测试这个？

单元测试，可能会在测试中断言 Redis 键及其值。

你能自己做这个并提交一个拉取请求吗？

可以审核

network server performance in progress scalability

资料来源

johanstokking

所有5条评论

我认为更好的方法是以另一种方式解决这个问题，这也提高了一般情况下的性能 - 从原型中分离出占用空间的数据并将它们分开存储 - 即recent_uplinks ， recent_downlinks等，将这些存储在列表中而不是编组的 protos 中也更有意义 - 这意味着我们实际上不需要查询现有消息，而只是附加一个新消息，这样效率更高，但是让我们从原型开始，然后从那里开始。
鉴于我们有字段掩码，拆分 proto 将非常简单，并且完全由 Redis 注册表实现处理。

所以建议是：

ns:devices:uid:foo:bar:recent_uplinks
ns:devices:uid:foo:bar:recent_downlinks
ns:devices:uid:foo:bar:mac_state:recent_uplinks
ns:devices:uid:foo:bar:mac_state:recent_downlinks
ns:devices:uid:foo:bar:pending_mac_state:recent_uplinks
ns:devices:uid:foo:bar:pending_mac_state:recent_downlinks
...
ns:devices:uid:foo:bar - 原型的其余部分

迁移将自动发生，类似于已在注册表中处理已弃用字段的方式。

rvolosatovs 于 2020-06-22

这里是什么状态？

johanstokking 于 2020-08-20

我预计这将在下周末为合并做好准备。
实施已完成数周，致力于重构，然后从那时起调整测试

rvolosatovs 于 2020-08-20

👍1

如果设备无法匹配，请考虑使返回的错误更清楚。例如参见https://github.com/TheThingsNetwork/lorawan-stack/issues/2394。

我们无法提供大量信息，但device_not_found表示无法找到设备，而可能是根本找不到 DevAddr，MIC 与找到的条目不匹配和/或者 FCnt 重置，而这对于找到的条目是不允许的。

johanstokking 于 2020-08-24

👍1

很好的建议，但我认为最好将其作为下一步进行，因为审查具有许多相对复杂的功能将是一个巨大的 PR

rvolosatovs 于 2020-08-24

👍1

此页面是否有帮助？

0 / 5 - 0 等级