Instagram如何跨洋扩展其基础设施？数据中心。Facebook在欧洲和美国拥有多个数据中心，但直到最近Instagram才使用美国数据中心。Instagram想要跨洋扩展其基础设施的主要原因是我们在美国的空间用完了。随着服务越来越多，Instagram已经到了需要考虑利用Facebook在欧洲的数据中心的地步。另一个好处：本地数据中心意味着欧洲用户的延迟更低，这有望在Instagram上带来更好的用户体验。2015年，Instagram将其基础设施从一个数据中心扩展到三个，以提供急需的弹性：我们的工程团队不想重蹈2012年AWS灾难的覆辙，当时弗吉尼亚的一场大风暴导致近一半的实例瘫痪。从三个数据中心扩展到五个很容易；我们只是增加了复制因子并将数据复制到新区域；然而，当下一个数据中心远离另一个大陆时，扩展就更难了。了解基础设施基础设施通常可以分为两种类型：无状态服务通常用于计算，根据用户流量进行扩展（按需扩展）。Django网络服务器就是一个例子。有状态服务通常用作存储，并且必须在数据中心之间保持一致。示例包括Cassandra和TAO。每个人都喜欢无状态服务，它们易于部署和扩展，并且可以随时随地启动。事实上，我们还需要像Cassandra这样的有状态服务来存储用户数据。运行具有过多副本的Cassandra不仅会增加维护数据库的复杂性，还会浪费容量，更不用说跨洋传输quorum请求的速度有多慢了。Instagram还使用TAO（DistributedDataStorageforSocialGraph）作为数据存储系统。我们将TAO作为每个分片的单个主服务器运行，没有从服务器为任何写入请求更新分片。它将所有写入转发到分片的主要区域。由于所有写入都发生在位于美国的主要区域，因此欧洲一侧的写入延迟是不可接受的。您可能已经注意到，我们的问题反馈基本上是光速。潜在的解决方案我们能否减少请求穿越海洋所需的时间（甚至使往返行程消失）？有两种方法可以解决这个问题。1.对Cassandra进行分区为了防止仲裁请求跨洋传输，我们考虑将数据集分为两部分：Cassandra_EU和Cassandra_US。如果欧洲用户的数据存储在Cassandra_EU分区中，美国用户的数据存储在Cassandra_US分区中，那么用户请求就不必长途跋涉来获取数据。例如，假设美国有五个数据中心，欧盟有三个数据中心。如果我们通过复制当前集群在欧洲部署Cassandra，复制因子将为8，仲裁请求必须联系8个副本中的5个。但是如果我们能找到一种方法将数据分成两组，我们就会有一个复制因子为5的Cassandra_US分区和一个复制因子为3的Cassandra_EU分区，每个分区都可以独立运行而不会影响其他分区。同时，每个分区的仲裁请求可以保持在同一个大陆上，从而解决了往返传输的延迟问题。2.TAO仅限于本地写入为了缩短TAO写入的延迟，我们可以将所有EU写入限制在本地区域。这对最终用户来说看起来非常相似。当我们向TAO发送写入时，TAO将在本地更新并且不会阻止sync向primary发送写入；相反，它将在本地区域中对写入进行排队。在写入数据的本地区域中，数据可立即从TAO获得，而在其他区域中，数据将在从本地区域传播后可用。这类似于今天的常规写入，数据从主要区域传播。虽然不同的服务可能会有不同的瓶颈，但如果我们着眼于减少或消除跨洋流量的想法，我们可以一一解决问题。经验教训与每个基础设施项目一样，我们在此过程中吸取了一些重要的教训。这里有几个主要的。不要急于进入新项目。在开始在新数据中心配置服务器之前，请确保您了解为什么需要在新区域部署服务、存在哪些依赖项以及新区域上线时系统的行为方式。另外，不要忘记反思您的灾难恢复计划并进行任何必要的更改。不要低估复杂性。总是在你的日程安排中留出足够的时间来犯错误、寻找意想不到的障碍以及学习你不理解的新依赖关系。您可能会发现自己无意中重新设计了构建基础设施的方式。了解取舍。成功总是有代价的。我们对Cassandra数据库进行分区后，通过降低复制因子节省了大量存储空间。然而，为了确保每个分区仍然处于灾难就绪状态，我们需要更多的前端Django容量来接受来自故障区域的流量，因为现在分区之间无法共享容量。要有耐心。在开启欧洲数据中心的过程中，我已经记不清说了多少次“哦，见鬼！”但事情总是最终会成功。这可能比您预期的要花更长的时间，但请耐心等待，整个团队将通力合作，这将非常有趣。原标题：Instagram如何跨洋扩展其基础设施，作者：SherryXiao
