如果您想要本地服务器的原因仅仅是出于性能原因,我会认真地推荐查看本地静态资产服务器,所有动态内容都将发送到伦敦.虽然geoDNS并非易事,但它比动态资产和数据库的强大实时同步更容易.许多站点(包括此站点)使用此机制来提高整体感知页面速度,并且它运行良好.

假设这不是这种情况,并且您确实需要两台服务器,我发现您的计划存在一个巨大的缺陷 – 1Mbps的国际带宽将因您的同步流量而相当饱和.你会希望你的网站不会太受欢迎,或者你将陷入痛苦的整个世界.

对于DNS,您处于相当有利的位置,因为您有一个明确定义的地址子集,您希望为其提供特定记录.据推测,您可以从您的提供商处获取一个网络列表,其中列出了“本地,带宽无限制”流量以及“国际,1Mbps上限”流量.如果您的提供商不能这样做,我会问他们他们实际上是如何进行速率限制的,因为那里必须有一个列表.最糟糕的情况是,如果他们只是基于“我们看到通过此BGP链接宣布的任何内容是本地的”,您仍然应该能够获得该链接上的前缀列表.

因此,DNS内容归结为“对于A记录请求到www.example.com,如果源地址在本地前缀列表中则为localip服务,否则为internationalip”.您为给定的DNS服务器编写脚本的方式取决于您;我会选择tinydns,因为我会尽我所能使用它,这对于这个特殊的任务来说非常棒.

但这大约占总问题的1％.你在城镇的动态资产方面有一个更大,更大的问题.

数据库实际上是(相对)简单的位. MySQL和Postgresql都支持多主复制,因此对任一数据库的写入都会自动复制到另一个(或多或少).设置并不是很简单,你需要监控它的bejesus以检测它何时中断并修复它,但它可以以相当标准化的方式进行.

另一方面,您的文件需要更多本地智能.要使其工作,您需要正确设计文件存储以允许复制工作.它更有趣,因为你说你需要支持删除.

真的,定期rsync是你最好的朋友.忽略事物的修改和删除方面一秒钟,如果你确保你的文件名不能双方碰撞(使用UUID或数据库PK作为所有文件名的基础将很好地工作)你应该能够做到每一方的定期rsyncs到另一方,并且在每一方创建的所有新文件将神奇地出现在另一方.你经常使用rsync取决于在所有内容同步之前你可以站立多少时间 – 这是你必须做的一个电话.您的应用程序还需要智能地处理(例如)DB记录已同步但文件尚未同步的情况.

删除会让事情变得更加困难,因为你不能只运行一个盲目的rsync -a –delete,因为发送者没有的任何内容都将从接收者中删除 – 这是丢失大量数据的好方法.我希望有一个删除日志,并且不时地通过它来删除另一方的内容.如果这不具有吸引力,你可以更加想象两端各有两个独立的文件系统(一个用于“本地数据”,另一个用于“另一端复制”),并且可以从你的应用程序访问它们,或者使用union文件系统层使它们看起来像Web服务器的一个文件系统.

修改只是一个完整的噩梦 – 你的风险是同时修改两台服务器,此时你只是搞砸了.在你所使用的那种“最终一致性”模型中(对于你被迫处理的地理分布式高延迟复制系统,这是唯一的选择)你根本无法在基础设施上处理这个问题级别 – 您必须在您的应用程序中做出某种妥协,以决定如何处理这些问题.您可以通过将文件系统视为仅附加存储来帮助解决问题(如果要修改文件,编写新版本并更新数据库以指向新记录),但由于您的数据库也只是最终一致,你无法完全解决问题.但是,至少如果你的数据库是单一的事实,那么你将保证一致性,如果不能保证正确性,那就是成功的一半.

我认为这几乎涵盖了一切.但重申一下,如果您不必使用地理位置分散的服务器,那么生活会变得更加简单.如果您正在实施此功能,因为它“听起来很酷”,请远离键盘.如果你想做很酷的事情,可以按照自己的时间做,或作为科学实验.你付出的代价是为你的雇主做最有效的事情,而不是给你一个怪异的阴茎异常勃起的东西.