进程间通讯 [英] Inter process communication
问题描述
使用文件进行进程间通信的优缺点是什么?让我给出我要问这个问题的背景信息.
What are the pros and cons of using a file for interprocess communication? Let me give some background of the context I am asking this question in.
问题是带有某些约束的经典生产者消费者问题.生产者是一组在一组机器上运行的协作过程，并使用广播相互通信.每个进程都有自己了解的本地用户，并通过上述广播机制让其他进程知道他们.到现在为止，广播/共享的状态信息尚未保留，但现在需要保留.
The problem is the classical producer consumer problem with some constraints. The producers are set of cooperative process running on a cluster of machines and communicate with each other using broadcasts. Each process has local users which it knows about and also lets the other processes know about them by the above broadcast mechanism. Till now the state information being broadcasted/shared was not being persisted but now it needs to be.
该系统已经在生产环境中运行了多年，现在已经为成千上万的用户提供了支持，并且人们对添加任何额外的依赖以增加对持久性的支持感到非常担忧.我们选择的路径是在现有进程中产生一个新线程，该线程将本地流量写入文件系统上的文件，然后由新进程读取(称为消费方)并持久化.我们通过这种方法看到的优势是:
This system has been running on production for years now supporting thousands of users and folks are understandbly very apprehensive about adding any extra dependency to this to add the support for persistence. The path we chose was to spawn a new thread in the existing process that writes the local traffic to a file on the filesystem which is then read by a new process( lets call it the consumer) and persisted. The advantages we see with this approach are:
- 我们免费提供持久性.如果新进程出现问题，我们在将其写入文件系统时不会丢失任何本地流量.只要消费者知道它停在哪里，只要出现它就可以开始处理数据.
- 使用排队库的普通旧unix文件IO没有学习上的困难.
- 最大的优点是，除了新的文件写入线程之外，我们根本不影响当前的生产者流程.
这种方法引起的一些担忧是:
Some of the concerns with this approach are:
- 文件锁定和争用及其对性能的影响.
- 确保已刷新写缓冲区，并且只有在将完整事件写入文件后，生产方才释放文件锁.消费者应阅读不完整的记录.
有什么想法吗?这种方法天真吗?我们是否应该为使用现成的持久性队列库而付出的启动时间支付初始费用?这里的重点是我们希望对当前流程产生最小的影响，并且不对其添加任何依赖关系.
Thoughts? Is this approach to naive and should we just pay the initial cost for the ramp up time for using an off the shelf persistent queue library? The main point here being we want to have the minimum possible impact on the current process and add no dependencies to it.
推荐答案
我最近遇到了这个选择，并考虑对Berkeley DB进行足够的了解以使用其队列机制.但是最终我还是决定使用Unix文件系统，并使用
I was faced with this choice recently and considered learning enough about Berkeley DB to use its queue mechanism. But ultimately I decided instead to use the Unix filesystem and write my own atomic queue primitives using Posix semaphores. If all processes are on one machine this is pretty easy. The atomic put function is about a dozen lines of code; the atomic get, because it has to wait if the queue is empty, is about three times the size.
我的建议是，您设计一个原子队列API ，它将隐藏这些详细信息. (遵循Parnas关于使用接口隐藏可能更改的设计细节的建议的经典示例.)您可以使用普通的Unix文件I/O来制作API的第一个版本.然后，您可以尝试使用诸如锁定"，"Berkeley DB"或信号量"之类的变体，所有这些都对当前进程的影响最小".
My advice is that you design an atomic-queue API that will hide these details. (Classic example of following Parnas's advice of using an interface to hide design details that are likely to change.) You can do the first version of the API using plain Unix file I/O. Then you can try variations like locking, Berkeley DB, or semaphores---all with the "minimum impact on the current process".
在尝试尝试之前，您不会知道性能影响.在真实文件系统上的文件锁定非常好； NFS上的文件锁定是负担.
You won't know performance impacts until you try something. File locking on real filesystems is pretty good; file locking on NFS is a bear.
这篇关于进程间通讯的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
