数据记录应用程序、服务器组件 - 单独的线程或单独的进程？答案

【问题标题】：Data logging application, server component - separate thread or separate process?数据记录应用程序、服务器组件 - 单独的线程或单独的进程？
【发布时间】：2015-11-08 16:49:19
【问题描述】：

我正在编写一个数据记录应用程序，它从外部设备读取一些值并定期将它们保存到文件中。另外，我希望应用程序有一个服务器组件，可以通过 TCP/IP 访问当前读数。

应用程序是（正在）在类 unix 环境中用 C 语言编写的。

我不确定服务器是否应该作为一个单独的进程运行（fork 在启动后自行离开）并使用一些 IPC 来获取数据，还是只作为一个单独的线程更好？

做出这样的决定需要哪些因素？

谢谢！

【问题讨论】：

您是否检查过您操作系统上现有的日志系统是否可以满足您的需求？在大多数类 unix 系统上，您有 syslog/syslogng/others。它们为此而生，记录在案，从本地/网络连接读取数据，并且还能够将日志转发到其他机器。
服务器应该只读取记录器写入的文件，还是应该通过独立发送从设备读取的内容来缩短它？
@alk，数据所在的文件是一个循环数据库，每个大约采样一次。 5 分钟，而服务器读取“几乎实时”的数据。所以直接从设备上读取是必须的。
@alk：描述中没有明确说明！不确定这是否适合实时，你是对的。但这可能取决于什么是实时：读取实时与写入实时不同（或在外部提供）
@hexasoft：我的评论并不是批评。总的来说，我完全同意使用现有的、经过良好测试的解决方案是首选方法。我也同意，更多地了解时间和数据质量/损失约束对于在此处提供任何有意义的建议至关重要。

标签： c multithreading unix

【解决方案1】：

如果您追求实时，请远离“另一个”进程，因为这只会在数据路径中引入另一个跃点，从而减慢传输速度。

有一个进程，实例化读取器线程，从设备中提取数据并将其推送到内部缓冲区，可能实现double-buffering，具体取决于设备的功能。

然后有一个记录器线程和一个发送器线程从这个内部缓冲区读取。

【讨论】：

好的，那么做出这样决定的唯一（或最重要的）因素是使用流程带来的延迟？我想我的问题是一般性的，尽管是在非常特殊的背景下提出的。我不在乎数据延迟是一秒还是微秒；该应用程序是一个气象站记录器，当我得到数据时，它们已经平均老化了大约半分钟。但与 RRD 5 分钟的平均数据点相比，这些数据是实时的。
如果延迟不是问题，最好看看周围的 syslogd 实现可以为您做什么。
Opps ...上面的评论应该是：“如果延迟不是问题，那么......”对不起。