你可能不应该这样做。使用分布式文件系统,对象存储(ala S3或GCS)或同步程序(如btsync或syncthing)。
如果你仍然想自己做,这将是具有挑战性的。你基本上正在建立一个分布式数据库,他们很难得到正确的答案。
乍一看,你可以结账一些东西,如etcd或raft,但不幸的是,etcd对大文件无法正常工作。
你可以上载,也将文件复制到使用ssh所有其他服务器。但是当服务器出现故障时会发生什么?或者当两个人同时更新同一个文件时会发生什么?
也许你可以设计它使得每个文件都有一个唯一的ID(可能基于其内容的哈希值,所以你可以放心地重复数据删除),并且这些文件不能被更新或删除,只是增加。这将解决同时发生的更新问题,但您仍然有停机问题。
一个办法是为每个服务器维护时添加的文件的仅追加版本日志:
VERSION | FILE HASH
1 | abcd123
2 | efgh456
3 | ijkl789
这样,您可以从服务器获取每个文件和一个单一的数字将足以知道何时添加文件。 (例如,如果你认为服务器A是5版本,你会得到通知,现在是第7版,你知道你需要同步2个文件)
你可以用一个数据库表做到这一点:
ID | LOCAL_SERVER_ID | REMOTE_SERVER_ID | VERSION | FILE HASH
您可以定期轮询并通过机器之间的ssh或http进行同步。如果一台服务器出现故障,您可以重试,直到它工作。
或者,如果你不希望有一个集中的数据库,这个你可以使用库像memberlist。每个节点的本地元数据可以是其版本。
无论哪种方式,都会有一个文件之间一定量的延迟上传到一台服务器,并且当它适用于所有的人。处理这个问题很困难,这就是为什么你可能不应该这样做。
[可能在Go负载平衡环境中可能存在网络文件共享?](http://stackoverflow.com/questions/30217922/network-file-share-possible-in-go-load-balanced-environment) – JimB
nope,这是另一种方法,我认为这可能是一个更好的选择。 – Dac0d3r
即使它不是一个确切的重复,它仍然是主题,并没有真正的编程相关(除非你有关于编程文件复制服务的具体问题,在这种情况下,问这个问题)。就像你的其他问题一样,你可能应该在ServerFault或SuperUser上提问。 – JimB