你基本上不走运，除非你以某种方式改变你的要求。
首先，特别是在Unix系统上，没有什么可以阻止多个进程写入相同的文件。在单个系统上，这不会是一个问题，如果两个或多个写入在文件中的同一空间发生冲突，您将遇到一个典型的争用条件，至于哪个将实际写入。由于它是在单个系统上，因此在字节级别具有完美的分辨率。
那么，就让多个进程写入同一文件而言，游戏是这些进程如何协调？他们如何确保他们不会互相踩踏。同样，在Unix中，有一种基于操作系统的锁定机制可以用来防止这种情况，但通常大多数系统都实现一个中央服务器，并通过该系统协调所有写入，然后它写入磁盘，同时减轻和处理任何冲突。
你的问题是双重的。
首先，您建议独立的日志进程不会合作，他们不会共享信息并协调他们对卷的写入。这就把一把扳手（一把大扳手）扔进了那里的作品中。
其次，您建议不仅让多个进程写入同一卷，而且建议它们写入的卷通过 SAN 共享。这是另一个扳手。
与 NFS 不同，SAN 不支持“文件系统”。相反，它们支持“存储”。基本上是块级设备。SAN，一旦你通过了一堆卷管理恶作剧，从操作系统的角度来看，实际上是相当“愚蠢的”。
我很确定您实际上可以在多台计算机上安装一个卷，但我不确定不止一台可以实际写入设备。这是有充分理由的。
简单地说，SAN 是块级存储。一个块，比如说，4K字节。这是 SAN 的“原子”工作单元。想要更改单个字节的数据？从 SAN 读取 4K 块，更改字节，然后将 4k 块写回。
如果您有几台计算机认为它们具有对SAN存储的“通用”访问权限，并将其视为文件系统，则您有一个损坏的文件系统。就是这么简单。这些机器将写入他们认为块应该是什么样子，而其他机器则用本地版本粉碎它。灾难。破坏。不开心。
即使让一台计算机写入 SAN，而另一台计算机从中读取数据也是很棘手的。它也很慢，因为读取器可以对磁盘的内容做出很少的假设，因此它需要读取和重新读取块（它不能缓存任何内容，如文件系统TOC等，因为，由于编写器的活动，它们在后面发生了变化 - 所以，再次读取它......再说一遍...）。
像NFS这样的东西“解决”了这个问题，因为你不再使用原始存储。相反，您使用的是实际的文件系统。
最后，从服务器流式传输出独立的日志文件没有错。他们仍然可以被查询。您只需重复查询并合并结果即可。
如果您有 5 台计算机流式传输，并且想要“中午 12：00 到中午 12：05 之间的所有活动”，则进行 5 次查询（每个查询一个到日志存储），并合并结果。至于如何有效地查询日志数据，这是一个索引问题，并且根据查询方式，并非不可克服。如果按时间查询，则按时间（每分钟、每小时、其他）创建文件并扫描它们。如果您的系统“很少读取”，这没什么大不了的。如果你需要更复杂的索引，那么你需要想出别的东西。
您可以使用数据库来写入文件和索引，但我怀疑您会发现许多人喜欢从他们无法控制的文件或它们下面更改的文件读取。
CouchDB可能会工作，或者类似的东西，因为它具有特定的抗崩溃，始终一致的数据库格式。它的数据文件始终可由数据库实例读取。这可能是您的一个选择。
但我仍然会做多个查询并合并它们。
