我有4个服务器，都在一个安全的本地networking上。
每个服务器运行script.php（每分钟）。
script.php从本地目录读取/ arc，进行文件testing，并将新文件写回到/ arc。
（这些是小的2kb的文本文件，每个服务器上的创build速度约为每秒20次）。
我希望所有的4弧线合并成一个。
例如，当script.php在server1上运行时，我想知道所有/ arc目录中的所有文件，而不仅仅是本地计算机上的文件。 当server1将文件写入到本地/ arc目录中时，servers2-4现在必须在/ arc目录中看到它。
另外值得注意的是，这些文件是易腐烂的，并且每10分钟就要扫描一次。
更新：目前，我将尝试NFS安装所有的目录。 弧顶也是tmpfs所以它应该是相当快的。 除非有人认为有一个更快的方法，我会试试这个：
1）在每台机器上，我将NFS挂载到所有其他机器上。 所以1个本地和3个NFS。
2）当script.php在任何一台机器上运行时，每个arc dirs将会有多个“cp”命令。 这将确保每台机器始终拥有最新的caching输出。 （是否每秒20个拷贝X个NFS地址的瓶颈？我希望不是。）
3）由于caching输出被复制到所有本地机器，这意味着script.php永远不必通过NFS挂载来读取文件。 弧caching的本地读取需要0.37秒。 通过NFS读取文件需要多长时间？ 比那更长？ 这就是如果我复制到一个中央位置会发生什么。
所以，我正在交易多个副本命令读取。 但我认为这是一个很好的交易，因为script.php请求的运行速度要尽可能快，这意味着读取caching文件的时间最短。
rsyncdevise用于1个源和1个目标之间的单向同步。 它不适用于4台主机之间可靠的双向同步。
像SyncThing或BitTorrent同步同步工具可能工作，虽然您的文件（20 /秒）的变化率可能太快，这些工具types。
我的build议是将其中一台服务器指定为“主”（或者设置第五台机器或NAS），并将所有其他机器的networking挂载（例如NFS） /arc指定为该主机，以便每台机器上的脚本实际上在同一个目录下工作。
如果您不能接受对托pipe该目录的单个机器的依赖，另一种select是使用诸如DRBD之类的东西来创build分布式块设备，该设备可以通过networking在块级复制。
每秒钟20个文件…在4台机器上。 这听起来像你真正想要的是一个数据库服务器。
MySQL，Postgres，SQLServer都可以轻松处理更新率。
如果每台机器需要复制到其他3台，那么每个文件需要n-1份副本。 所以，每秒产生20个文件的4台机器是每秒120个拷贝。 如果你需要第五台机器，那么这个数字就会增加一倍。 第六台机器将再次翻倍。 你可能不会认为你会成长，但你会。
如果你打算每个文件创build完毕后，每次运行script.php时都会有3个scp命令。 考虑到scp需要多长时间对会话进行身份validation，每次运行可能需要1-2秒。 这是每秒60秒。
相反，你可以创build文件，并有一个循环运行rsync另一个进程。 每次运行rsync都会提取任何新文件。 创build文件到创build其他服务器之间的时间为秒或分钟。 如果您想要备份数据，并且可以在发生计划外停机时承受一些数据丢失，那么也可以。 如果您希望其他服务器立即获得信息，这是不够的。
另一方面，如果你使用一个数据库，所有3台机器都会caching到数据库的连接，并且更新会非常快。 数据将立即可用。
如果你对服务器有很好的控制，那么我认为围绕像RabbitMQ这样的消息传递服务器是可以走的。 您不需要创build文件，而是将消息放入队列中，脚本将订阅这些队列事件，进行处理，然后将结果放回队列中供其他服务器使用。
我不认为rsync是要走的路。 lsync的模式可能是有趣的，因为它lsync内核事件的变化，但它是一个主/从安排，我不知道它适用于你的情况。
@Andy表示，你可能会用某种共享的networking文件系统做的更好。 （NFS，GFS，Gluster）的想法，还有更多。 尽pipe如此，请注意locking问题，以及如果连接到文件服务器中断会发生什么情况。
@ TomOnTime的回应可能是正确的，他说基于文件的系统可能是错误的select。 基于SQL的解决scheme的主要优点是您可能已经build立了数据库服务器。 尽pipe在SQL中使这种事情有效，但是还是有比你想象的更多的陷阱。
编辑：
如果你说这是一个caching系统，你可能也想看看memcached，redis，甚至是清漆。
您的应用程序是否事先知道他们期望在caching中，而不必要求清单？