方案 A：
为了在同一主机上运行的两个进程之间共享一个读/写内存块，Joe 从两个进程映射同一个本地文件。
方案 B：
为了在两个不同主机上运行的两个进程之间共享一个读/写内存块，Joe 在主机之间通过 nfs 共享一个文件，然后从两个进程中映射共享文件。
有人尝试过场景 B 吗？场景 B 中出现的哪些额外问题不适用于场景 A？
问问题
6698 次
3 回答
5
如果没有一些额外的操作，Mmap 不会共享数据。
如果您更改文件的 mmaped 部分中的数据，则更改将仅存储在内存中。它们不会被刷新到文件系统（本地或远程），直到msync或 munmap 或关闭甚至决定 OS 内核及其 FS。
When using NFS, locking and storing of data will be slower than if using local FS. Timeouts of flushing and time of file operations will vary too.
On the sister site people says that NFS may have poor caching policy, so there will be much more I/O requests to the NFS server comparing I/O request count to local FS.
于 2012-04-29T02:21:27.453 回答
4
You will need byte-range-lock for correct behavior. They are available in NFS >= v4.0.
于 2012-04-29T19:35:38.283 回答
0
我会说场景 B 有各种各样的问题（假设它按照评论中的建议工作）。最明显的是标准并发问题 - 2 个进程共享 1 个资源而没有任何形式的锁定等。这可能会导致问题......不确定 NFS 在这方面是否有自己的特殊怪癖。
假设您可以以某种方式解决并发问题，您现在依赖于维护稳定（和快速）的网络连接。显然，如果网络中断，您可能会错过一些更改。这是否重要取决于您的架构。
我的想法是这听起来像是在不同机器上共享一块内存的简单方法，但我不能说我听说过它正在完成，这让我觉得它不是那么好。当我想到在 procs 之间共享数据时，我会想到 DB、消息传递或专用服务器。在这种情况下，如果您将一个 proc 设为 master（处理并发并拥有该概念 - 即无论这个人说什么是数据的最佳副本），它可能会起作用......
于 2012-04-28T21:58:08.003 回答