克服分布式系统中的连接问题：航空航天

作者：Jason Myers / 开发者
2024年6月28日

对于轨道上的航空航天操作，维护和修理提出了相当大的挑战。派遣技术人员修复卫星上的组件并非易事。因此，在发射和部署此类设备之前，尽可能多地规划各种场景变得越来越重要。

为了了解轨道设备的运行状况，公司需要数据。如果数据流中断，首要任务是重建数据流，以避免昂贵的设备变得无用。

企业可以使用几种不同的策略来帮助缓解或克服分布式系统中较差或不稳定的连接。在这里，我们假设有许多边缘设备尝试将数据发送到中央枢纽。

传输前

在尝试传输数据之前，您可以实施一些本地策略，以提高传输效率。其中一些策略将取决于设备上可用的资源，但同时，可用资源应反映连接问题可能产生的潜在需求。

• 数据缓存：如果您需要使用本地生成的一些数据，这将特别有用。在设备等待将其传输到中央枢纽时，将数据缓存在设备上以使其可用，这有助于保持系统运行。
• 压缩：这非常简单明了。尽可能压缩您的数据，以减少将数据发送到中央枢纽所需的吞吐量。
• 优先级调度：某些数据是否比其他数据更重要？提前了解这一点并优先传输该数据，可以确保在有限的连接窗口中，该数据更有可能到达中央枢纽。
• 校验和与哈希值：如果您担心数据损坏，可以在本地为该数据生成校验和或哈希值。在传输中包含这些校验和有助于中央枢纽验证数据。

传输

您可以使用许多方法为数据构建安全保障。虽然此列表绝非详尽无遗，但希望它能帮助您开始进行相关讨论。

工具

我将进一步细分本节，因为您最终选择的工具可能会影响您的配置选项。因此，让我们看一下一些可以帮助管理数据的工具，以便您可以更轻松地利用不同的配置选项。

InfluxDB：这应该不足为奇，但拥有本地时间序列数据库实例有助于管理来自设备上各种系统和传感器的所有数据。特别是，支持边缘数据复制 (EDR) 的单节点实例是理想选择。此功能创建了一个持久的本地数据队列，这样，如果您的连接失败或中断，数据库将继续收集数据，并在连接恢复后刷新队列。

Kafka：使用 Kafka 队列是另一种应对间歇性或不可靠连接的方法。Kafka 队列的功能与标准发布-订阅不同。队列系统将数据保存在队列中，一旦应用程序读取该数据，数据就会被删除。（在发布-订阅方法中，数据可以持久化，因此在读取后不会被清除。）多个设备可以发布到同一个队列，这在队列具有可靠连接时非常有用。与 InfluxDB 类似，Kafka 队列可以很好地水平扩展，并且非常适合分布式系统。

配置

在 InfluxDB 和 Kafka 之间，您应该能够收集和存储数据。配置应用程序逻辑以解决连接问题是完全不同的领域。以下是一些需要考虑的概念和方法。

• 动态调整：这涉及根据当前的连接状况调整传输速率和方法。在连接较差的时期，您希望此应用程序逻辑降低传输速率或切换到更强大的协议来传输数据。
• 前向纠错 (FEC)：这会将验证数据的负担转移到接收器，因此如果您的边缘设备资源有限，这是一种解决方法。这种方法在传输中包含额外的数据，使接收器能够检测和纠正错误，而无需重新传输。上面提到的关于生成校验和或哈希值的方法可以归入此类，当然，毫无疑问还有其他选项。
• 边缘计算：这就是在边缘拥有数据库有帮助的地方。如果您有可用资源，可以在边缘本地处理数据，仅将清理和处理后的数据发送到中央枢纽。这最大限度地减少了您需要传输的数据总量。
• 延迟容忍网络 (DTN)：这是一种存储转发方法。DTN 协议非常适合经历长时间延迟和中断的环境。这类似于消防员的水桶传递，数据存储在中间节点，直到连接可用时再转发到中央枢纽。
• 优化路由算法：有几个选项属于此类。
  • 机会路由：这涉及编写应用程序逻辑，以利用任何可用的通信机会来转发数据。您可以通过根据当前网络状况动态选择路径来实现此目的。
  • 多路径路由：与其依赖单一数据传输路径，不如考虑配置多条路径以增加成功交付的机会。如果您将此数据发送到中央 InfluxDB 实例，则数据库具有自动重复数据删除功能。这种方法最终可能会导致更多聚合数据传输，因此最好将其作为备份，而不是克服连接问题的主要策略。
• 低带宽和高延迟网络的协议
  • 轻量级协议：在有意义的情况下，您可以使用专为低带宽环境设计的通信协议，例如受限应用协议 (CoAP) 而不是 HTTP。
  • 高延迟协议：同样，倾向于可以使用处理高延迟的成熟协议，例如针对长距离通信优化的 TCP 变体。

总结

虽然任何单一配置选项都不太可能是航空航天公司正在寻找的灵丹妙药，但动态应用程序逻辑与拥有合适的工具来收集和管理数据相结合，可以在解决不可靠或间歇性连接问题方面取得重大进展。

要了解有关航空航天公司如何使用 InfluxDB 的更多信息，请单击此处。在此处免费试用 InfluxDB。