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

如何解决什么是存储设备配置信息的好机制

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

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

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

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

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

解决方法

在我看来，只有前 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++ Concurrency in Action 的第 5 章（C++ 内存模型和原子类型的操作）。顺便说一句，如果您可以使用填充来确保 DeviceData（完整包含博客文章中使用的 m_version1 和 m_version2 字段）与一个或多个缓存行的大小完全相同（在大多数 CPU 架构中，缓存行是 64 字节）那么您的实现将不会受到错误共享的影响（这会不必要地降低性能）。

最后一步是避免将低级共享内存操作暴露给开发人员。因此，编写一个简单的包装器 API，例如有四个操作：connect() 到共享内存段和 disconnect()，以及 readDeviceData() 和 updateDeviceData()。