Facebook是如何从简单的数据库分片扩展到分布式分片通用平台？

多年来，Facebook已从一种基本的Web服务器体系结构演变为一个复杂的体系结构，其中包含成千上万的服务在后台运行。扩展Facebook产品所需的各种后端服务并不是一件容易的事。而且发现我们的许多团队正在构建具有重叠功能的自定义分片解决方案。为了解决此问题，我们将Shard Manager构建为通用平台，以促进可靠分片应用程序的有效开发和操作。

使用分片扩展服务的概念并不新鲜。但是，据我们所知，我们是业界唯一在我们的规模上获得广泛采用的通用分片平台。Shard Manager管理生产中成百上千个应用程序中成千上万个服务器上托管的数千万个分片。

多年来，Facebook已从一种基本的Web服务器体系结构演变为一个复杂的体系结构，其中包含成千上万的服务在后台运行。扩展Facebook产品所需的各种后端服务并不是一件容易的事。而且发现我们的许多团队正在构建具有重叠功能的自定义分片解决方案。为了解决此问题，我们将Shard Manager构建为通用平台，以促进可靠分片应用程序的有效开发和操作。

使用分片扩展服务的概念并不新鲜。但是，据我们所知，我们是业界唯一在我们的规模上获得广泛采用的通用分片平台。Shard Manager管理生产中成百上千个应用程序中成千上万个服务器上托管的数千万个分片。

分片简介

人们熟悉分片作为扩展服务以支持高吞吐量的一种方式。下图说明了典型Web堆栈的缩放比例。Web层通常是无状态的，并且易于扩展。由于任何服务器都可以处理任何请求，因此可以使用多种通信量路由策略，例如轮循或随机。

另一方面，缩放数据库部分由于其状态是不平凡的。我们需要应用一种方案来确定性地跨服务器分布数据。像散列这样的简单散列方案hash(data_key) % num_servers 可以散布数据，但是当按比例添加服务器时，存在将数据混排的问题。一致性哈希通过仅将一小部分数据从现有服务器重新分配到新服务器来解决此问题。但是，此方案要求应用程序具有细粒度的键才能使统计负载平衡有效。由于其本质，一致性哈希支持基于约束的分配的能力（例如，应将欧洲联盟用户的数据存储在欧洲数据中心以降低延迟）。结果，只有某些类型的应用程序（例如分布式缓存）才采用此方案。

一种替代方案是将数据显式分区为分配给服务器的分片。数十亿用户的数据存储在许多数据库实例中，每个实例都可以视为一个分片。为了提高容错能力，每个数据库分片可以具有多个副本（又名副本），每个副本都可以发挥不同的作用 （例如，主要或次要），具体取决于一致性要求。

明确分配给服务器的分片具有合并各种约束（例如，哈希解决方案无法支持的位置首选项）的能力。我们发现分片方法比散列方法更灵活，并且适合更广泛的分布式应用程序的需求。

采用这种分片方法的应用程序通常需要某些分片管理功能才能可靠地大规模运行。最基本的功能是故障转移功能。如果发生硬件或软件故障，系统可以将客户端流量从故障服务器转移开，甚至可能需要在运行状况良好的服务器上重建受影响的副本。在大型数据中心中，服务器始终计划停机以执行硬件或软件维护。分片管理系统需要通过主动将副本从服务器上移开以确保每个分片具有足够的正常副本，以便在必要时将其删除。

另外，可能不均匀且不断变化的分片负载需要负载平衡，这意味着必须动态调整每个服务器主机的分片集，以实现统一的资源利用率并提高整体资源效率和服务可靠性。最后，客户端流量的波动需要分片扩展，系统在每个分片的基础上动态调整复制因子，以确保其平均每个副本负载保持最佳状态。

我们发现，Facebook的不同服务团队已经在构建自己的自定义解决方案，以实现不同程度的完整性。常见的情况是，服务能够处理故障转移，但是负载平衡的形式非常有限。这导致次优的可靠性和较高的操作开销。这就是为什么我们将Shard Manager设计为通用的分片管理平台的原因。

使用分片管理器将分片作为平台

多年来，已将数百个分片应用程序构建或迁移到Shard Manager上，具有历史超增长的上十万个服务器上总共有上千万个分片副本，这些应用程序有助于各种面向用户的产品（包括Facebook应用程序，Messenger，WhatsApp和Instagram）的平稳运行。

首先，与Shard Manager集成意味着简单地实现一个由add_shard 和原语组成的小而直接的界面drop_shard 。其次，每个应用程序都可以通过基于意图的规范来声明其可靠性和效率要求。第三，使用通用约束优化求解器使Shard Manager能够提供通用的负载平衡功能，并轻松添加对新平衡策略的支持。

最后但并非最不重要的一点是，通过完全集成到包括容量和