什么是存储设备配置信息的好机制

Question

我有 10k 台设备，它们具有相同的配置属性但值不同。配置文件包括名称、类型、型号、制造年份、温度、使用情况、状态。前 4 个值不变，后 3 个值每隔几秒就不断变化。每台设备都连接了一台计算机。

在以下两种存储配置的方式中，哪种方式更好？ 1）方式1：将配置信息放入json文件中，将json文件保存在与设备相连的电脑上； 2）方式2：将配置信息放入数据库表中。

方式1的优点是延迟少，但数据不易维护。方式 2 具有更多延迟但更易于维护。我们可以创建一个 API 来从表中获取数据。如果设备越来越多，方式 2 也存在 TPS 问题。例如，如果有 80k 个设备，并且每个设备都在同时将配置数据写入数据库表。

更新：正如 Ciaran McHale 所说，这三个变量是动态信息，所以我在问题中添加了以下信息：

这 3 个变量（温度、使用情况、状态）是动态信息，可以保存在内存中，但我们也希望将最终值保存在某个地方，以便在重新启动设备或应用程序时我们知道这些值。所以我的问题是关于保持这些最终价值的良好机制。 （数据库表与本地 json/xml/txt 文件）。

Answer 1

在我看来，只有前 4 个变量（类型、型号、制造商和年份）属于配置文件。由于其他 3 个变量（温度、使用情况、状态）每隔几秒就会改变一次，它们实际上是应该保存在内存中的动态状态信息，您应该提供一个 API 以便检查这些状态信息。 API 可能是，例如，通过客户端-服务器套接字连接，或通过共享内存。你可能会说，“我不能那样做，因为[这样那样]”，所以我建议你用这样的推理更新你的问题。这样做可能会帮助您获得更多有用的答案。

因更新问题中提供的额外信息而进行编辑...

我将要建议的内容适用于 Linux。我不知道其他操作系统。您可以通过man shm_open 和man mmap 来了解共享内存。共享内存段可以在进程重新启动后继续存在，并被备份到文件（在磁盘上），因此它可以在机器重新启动后继续存在。我（可能不正确）的理解是，大多数情况下，文件的内容将缓存在内核缓冲区中，虚拟内存会将这些内核缓冲区映射到进程的地址空间，因此读/写将是仅内存操作；因此您不会遭受频繁的磁盘 I/O。

为简单起见，我将假设每个设备都需要存储相同种类的动态信息，这可以用一个固定长度的struct来表示，例如：

struct DeviceData {
  double       temperature;
  SomeEnum     usage;
  AnotherEnum  status;
};

您可以拥有一个足够大的共享内存段来存储一个数组，例如 100,000 个DeviceData 结构。每个设备的静态配置文件将包含以下条目：

name="foo";
type="bar";
model="widget";
manufacture_year="2020";
shared_memory_id="/somename";
shared_memory_array_index="42";

静态配置文件中的最后两个条目指定进程应该连接到的共享内存段，以及它应该用来更新与进程关联的DeviceData 的数组索引。

如果以上内容似乎适合您的需求，那么要处理的挑战是有效同步以在共享内存中读取/更新DeviceData。在名为A scalable reader/writer scheme with optimistic retry 的博客文章中讨论了一种良好的基本方法。那篇博客文章使用 C# 来说明这个概念。如果您使用的是 C++，那么我建议您阅读 Anthony Williams 的C++ 并发操作的第 5 章（C++ 内存模型和原子类型的操作）。顺便说一句，如果您可以使用填充来确保DeviceData（完整的包含博客文章中使用的m_version1 和m_version2 的字段）与一个或多个缓存行的大小完全相同（一个缓存行是64大多数 CPU 架构中的字节数），那么您的实现就不会受到 错误共享 的影响（这会不必要地降低性能）。

最后一步是避免将低级共享内存操作暴露给开发人员。因此，编写一个简单的包装 API，其中包含四个操作：connect() 和 disconnect() 来自共享内存段，readDeviceData() 和 updateDeviceData()。