如何在多个不同地理位置的服务器上托pipe单个网站

首先，简单，直接，而且最重要的是， 强大的解决scheme是放弃有两台服务器的计划，只需从适当的中心位置运行一台机器即可。 虽然我理解不承载本地服务器的任何东西的理由，但是由于国际带宽的限制，我没有看到任何需要本地服务器存在的问题。

如果你想要一个本地服务器的原因是纯粹的性能原因，我会认真的build议看一下本地的静态资产服务器，所有的dynamic的东西去伦敦。 虽然geoDNS不是微不足道的，但它比dynamic资产和数据库的健壮的实时同步要容易得多。 许多网站（包括这个网站）都使用这种机制来提高网页整体感知速度，而且效果相当好。

假设情况并非如此，而且确实需要两台服务器，我们发现计划中存在一个巨大的缺陷 – 即1Mbps的国际带宽将会被同步stream量相当饱和。 你会希望你的网站不太受欢迎，否则你将处于一个痛苦的世界。

与DNS相比，您处于相当有利的位置，因为您已经明确定义了要为特定logging提供服务的地址子集。 据推测，你可以从你的提供商那里得到一个netblock列表，描述什么是“本地，带宽无限”的stream量，什么是“国际，1Mbps上限”的stream量。 如果你的提供者不能这样做的话，我会问他们究竟是怎么做的，他们实际上是在限制速度，因为在那里有一个列表。 最坏的情况是，如果他们只是基于“我们在这条BGP链路上看到的任何东西是本地的”来做的话，那么您仍然应该能够获得该链路上的前缀列表。

所以，DNS的东西归结为“对于www.example.com Alogging请求，如果源地址在本地前缀列表中，则服务于localip ，否则为internationalip ”。 如何为给定的DNS服务器编写脚本取决于您; 我会和tinydns一起去，因为我尽我所能地使用它，在这个特殊的任务中，这是非常棒的。

但这是总问题的1％左右。 在城镇的dynamic资产方面，你有更多的问题。

数据库实际上是（相对）容易的一点。 MySQL和PostgreSQL都支持多主复制，因此写入任何一个数据库都会自动复制到另一个（或多或less）。 设置并不是一件简单的事情，你需要监视Bejesus，以便检测它是什么时候中断和修复的，但是可以用一种相当标准化的方式。

另一方面，你的文件需要更多的本地情报。 要做到这一点，您需要正确devise文件存储以允许复制工作。 这更有趣，因为你说你需要支持删除。

真的，周期性的rsync是你最好的朋友。 忽略修改和删除的东西一秒钟，如果你确保你的文件名不能碰撞双方（使用UUID或数据库PK作为所有文件名的基础将很好地工作），你应该能够做每一边到另一边的周期性的rsyncs，每一边创build的所有新文件都会神奇地出现在另一边。 rsync的频率取决于你在一切事物同步之前能够维持多less时间 – 这是你必须要做的一个调用。 您的应用程序还需要智能地处理（例如）DBlogging已同步但文件尚未同步的情况。

删除使得事情变得更加困难，因为你不能只运行一个盲目的rsync -a --delete因为发送者没有的任何东西都会从接收者中删除 – 这是丢失大量数据的好方法。 我宁愿有一个删除日志，并通过它运行，然后从另一端删除的东西。 如果这样做没有吸引力，那么可以在两端使用两个独立的文件系统（一个用于“本地数据”，另一个用于“另一端的副本”），并从应用程序访问它们，或者使用联合文件系统层，使它们看起来像一个文件系统的Web服务器。

修改只是一个完整的噩梦 – 你的风险是同时修改两台服务器，在这一点上，你只是拧了。 在这里您正在使用的“最终一致性”模型（对于您不得不处理的地理分布式高延迟复制系统是唯一的select），您根本无法在基础结构级别 – 您必须在应用程序中做出某种妥协，才能决定如何处理这些问题。 您可以通过将文件系统视为仅附加存储（如果要修改文件，编写新版本并更新数据库以指向新logging）来帮助解决这种情况，但是由于您的数据库也是最终一致，你不能完全解决问题。 至less如果你的数据库是单一的事实点，但是你将保证一致性，如果不能保证正确性，这是一半的战斗。

我认为这只是涵盖了一切。 但是要重申一下，如果你不必使用分布在不同地理位置的服务器，生活就会简单得多。 如果你正在实现这个，因为它“听起来很酷”，离开键盘。 如果你想做一些很酷的东西，可以在你自己的时间做，或者做一个科学实验。 你得到的报酬是为你的雇主做最有效的，而不是什么让你成为一个极端的极端主义者。