我想有2个相同的Web服务器：一个主人和一个奴隶。 在主站上新build的修改/创build的文件应该立刻在从站上复制（在一分钟内）。
我不想使用rsync，因为它扫描所有文件来计算发送的增量。 我不想使用像GLUSTER这样的分布式文件系统，因为我担心它可以接受很多小的写入。 不过，我可以等待一分钟，将所有的修改都冲刷到从机上。
你有什么工具我应该使用的想法？
我不明白你为什么不想使用rsync; 毕竟，究竟是为了什么…
既然你说你不想使用集群文件系统，那么使用ServerA（共享/导出）上的www文件夹将它挂载到ServerB上，就像wwwRoot一样。 ServerB使用完全相同的文件而不是复制。
我没有尝试过，但这可能会做你在问什么。
如果您的Web应用程序的文件保持在版本控制（您确实拥有版本控制中的文件，是吗？），您可以编写脚本将这些文件从VCS中取出，并重新启动Web服务器服务（Apache， NGINX等）。 你甚至可以在cron下运行，以便每次更新回购（我build议检查一个标签而不是分支或只是主），它会自动更新网站。
drbd将允许块级别的复制，但是，如果您正在从机上进行任何写操作，您可能要使用OCFS2或GFS来支持群集locking。 如果你可以通过NFS从主机挂载主机，并且可以直接写入NFS挂载，则可以避免使用群集locking文件系统。
GlusterFS会更加无缝，但是，很多小写操作似乎有时候会有些积压。 OpenAFS是相似的，但是几乎所有的分布式文件系统都适合这个账单。 一个双节点的HDFS可能也会做你所需要的。
@gwaldo，至于没有使用rsync，如果你有成千上万的文件，可能需要一分多钟才能遍历树来find修改过的文件。
rsync不应该扫描所有文件来计算其增量，默认情况下它使用快速检查algorithm，只查看大小或修改时间改变的文件。 如果你没有几百万个文件，rsync运行应该是相当快的。
否则，你可能需要一个自定义的解决scheme，需要监视可以修改数据并在程序closures文件后发送的应用程序。
这些要求并不是完全不寻常的，但它看起来很麻烦。
对于大多数有意义的商业Web应用程序来说 ，高可用性的负载平衡代理应该几乎无处不在。 这意味着使用任何合适的：dns循环，haproxy，ipvs，pfsense，f5，netscalers，cisco ace等
提供静态内容的Web服务器应该是无状态的。 除了丢弃连接之外，如果任何一个Web服务器消失，对用户应该几乎没有影响。 所以，不需要在机器之间进行磁盘复制。 使用上面提到的LB以较less的努力完成相同的事情。 复制会造成脆弱的依赖关系和支持噩梦，可能会导致一切事情失败。 如前所述从内部部署服务器推送git或rsync通过ssh是更好的主意。 如果将内容推送到成千上万的节点，twitter上的谋杀gem是非常棒的。
应用程序服务器，任何基于改变的数据产生网页的应用程序也应该是相对无状态的。 绝对使用像Nginx这样的应用程序干净，滚动，指数部署。 数据应保存在数据库（sql / nosql）或RESTful数据提供程序中。
经过彻底testing的故障转移应该保留用于保护数据库和其他关键组件。 为了提高性能，如果testing应用程序的数据库并发写入瓶颈超出了硬件（扩展）处理能力，那么可以考虑使用日志结构存储引擎（如riak的bitcask）的可靠nosql。
如果这不是一个web应用程序，但处理大量的数据，评估一个MapReduce框架，如使用他们的HDFS的Hadoop。
DRDB +心跳Apache群集可以启用…我个人testing过这个…它工作正常
您可能应该使用incrond来监视已更改的文件，而不是定期（盲目地）运行。
您可以使用$#variables（代表与事件关联的文件名）分别同步每个更改的文件。 如果您希望避免在每次更改之后扫描path中的所有文件，则可能需要这样做。 我还没有尝试过。
也许你应该看看Unison ：
Unison与configurationpipe理软件包（CVS，PRCS，Subversion，BitKeeper等），分布式文件系统（Coda等），单向镜像实用程序（rsync等）以及其他同步器（Intellisync，Reconcile等）。
这是一个howto 。