进程间通信

Question

使用文件进行进程间通信的利弊是什么？让我介绍一下我提出这个问题的背景情况。

问题是具有一定约束条件的经典生产者消费问题。生产者是一组在一组机器上运行的协作进程，并使用广播相互通信。每个进程都有它知道的本地用户，并通过上述广播机制让其他进程了解它们。到目前为止，被广播/共享的状态信息并没有被保留，但现在需要这样做。

这个系统已经在生产上运行多年了，现在支持成千上万的用户，人们可以理解，他们非常担心增加任何额外的依赖来增加对持久性的支持。我们选择的路径是在现有进程中生成一个新线程，该线程将本地通信量写入文件系统上的一个文件，然后由一个新进程(让我们称它为使用者)读取该文件并持久化。我们看到这种方法的优点是：

1. 我们免费获得坚持。如果新进程存在问题，则在将其写入文件系统时，我们不会丢失任何本地通信量。只要消费者知道它停在哪里，它就可以开始处理数据。
2. 没有使用队列库的学习曲线--它是普通的unix文件IO。
3. 最大的好处是，除了文件写入的新线程之外，我们根本不影响当前的生产者进程。

对这一办法的一些关切是：

performance.

• Making上的

1. 文件锁定和争用及其对该文件的影响，确保写入缓冲区被刷新，并且生产者只在将完整事件写入文件后才释放文件锁。消费者应阅读不完整的记录。

有什么想法？这种方法是否幼稚，我们是否应该为使用现成的持久性队列库而花费的初始成本？这里的要点是，我们希望尽可能减少对当前流程的影响，并且不向其添加依赖项。

Answer 1

最近，我面临着这个选择，我考虑了解足够多的伯克利DB来使用它的队列机制。但最终，我决定使用Unix文件系统，并使用Posix semaphores编写自己的原子队列原语。如果所有进程都在一台机器上，这是相当容易的。原子put函数大约有十几行代码；原子get，因为如果队列是空的，它必须等待，大约是队列大小的三倍。

我的建议是设计一个原子队列API来隐藏这些细节。(遵循Parnas关于使用接口隐藏可能会更改的设计细节的建议的经典示例。)您可以使用普通Unix文件I/O完成API的第一个版本，然后您可以尝试类似锁、Berkeley DB或信号量之类的变体--所有这些都具有“对当前进程的最小影响”。

除非你尝试一些东西，否则你不会知道性能的影响。在真正的文件系统上进行文件锁定是非常好的；NFS上的文件锁定是一种负担。