Facebook 的基础设施由许多分布在不同地理区域的数据中心组成，它们承载着数百万台服务器。这些服务器运行许多系统，从前端 web 服务器到新闻摘要聚合器，再到我们的消息和实时视频应用程序。除了常规的代码推送之外，我们每天还会向服务器推送数千个配置更改。因此，我们的服务器执行数万亿次配置检查是相当常见的。配置检查的其中一项是 web 服务器个性化用户体验，例如它文本对一个用户以英文显示，对另一个用户以葡萄牙语显示。
在本文中，我们将介绍位置感知分发系统 (Location-Aware Distribution，LAD)，这是一个新的对等系统，用于处理对数百万台服务器的配置更改的分发。我们发现，LAD 在发布大型更新方面明显优于之前的程序系统，支持文件现在是 100MB，而之前为 5MB，同时每个发布者支持约 40000 个订阅者，而之前为 2500 个订阅者。
正如我们在 SOSP 2015 年的论文 中所描述的，Facebook 的配置管理系统 (称为 Configerator) 使用开源的分布式同步服务 ZooKeeper 来分发配置更新。
ZooKeeper 中的所有数据都存储在一个统一的数据存储中。每个 ZooKeeper 节点 (znode) 可以包含数据或其他子 znode。可以使用分层路径 (例如/root/znode/my-node) 访问每个 znode。从 ZooKeeper 中读取数据的客户端可以在 znode 上设置观察器；当 znode 被更新时，ZooKeeper 会通知这些客户端，以便他们可以下载更新。
ZooKeeper 强大的数据一致性和严格的分发保证是我们可靠地扩展和运行系统的关键。然而，随着我们的基础设施发展到数百万台机器，我们发现 ZooKeeper 变成了瓶颈。
严格的排序保证 ：ZooKeeper 的一个关键特性是它提供了严格的排序保证，这意味着写操作总是被一个线程按顺序处理。为了确保读操作不被中断，ZooKeeper 会交叉进行读和写处理。我们发现，对特定 znode 的更新可能会触发大量的监控，而这反过来又可能触发大量来自客户端的读取动作。一些这样的写操作可能导致更新阻塞。
巨大的集群 ：当数据 znode 被更新时，ZooKeeper 会通知所有感兴趣的客户端。当传入的客户端请求大于 ZooKeeper 处理能力时，这可能会引发一个巨大的集群问题。
大型更新可能会使 NICs 饱和 ：我们的一些配置文件的大小最多为 5 MB。给定一个 10gb /s NIC，我们发现一个盒子只能服务大约 2000 个客户。如果经常更新这样的文件，我们发现更新文件可能需要 10 秒的时间传播到所有需要的客户端。
当我们开始设计新的分发系统时，我们提出了几个要求，包括：
支持大型更新：将文件大小从 5 MB 增加到 100 MB。
独立的数据存储：ZooKeeper 将一个数据存储与它的分发框架结合在一起。我们希望将数据存储和分发组件分开，以便我们能够分别对每个组件进行大小和规模的调整。
分发能力：可以支持数百万客户。
延迟：将发布延迟限制在 5 秒以内。
配置文件：相较于我们以前基于 zookeeper 的系统，这个系统支持 10x 配置文件的数量，
可以满足巨量集群和更新率激增的情况。
LAD 由两个主要组件组成，它们通过 Thrift RPC 相互通信:
代理： 每个机器上运行的守护进程，为任何有需要的应用程序提供配置文件。
分发器： 该组件担当两个角色。首先，它对数据存储进行轮询以获取新的更新。其次，它为一组对更新感兴趣的代理构建一个分发树。
上图显示了 LAD 如何将代理组织到一个分发树中，它本质上是一个组织良好的对等网络。如步骤 1 所示，代理代表运行在该框上的应用程序向分发服务器发送“订阅”请求。分发服务器通过发送“添加对等点”请求 (步骤 2) 将代理添加到分发树中。一旦代理被添加到树中，它就开始接收元数据 (步骤 3) 更新。这些内容被过滤，代理通过内容请求进行响应 (步骤 4)。如果父类拥有内容，它将立即将其发送给子类；否则，它将从父服务器下载内容 (步骤 5)。
通过对树的使用，LAD 确保更新只推送给感兴趣的代理，而不是队列中的所有机器。此外，父机器可以直接向子机器发送更新，从而确保根服务器附近的任何一台机器都不会过载。
我们在使用 ZooKeeper 上的一个重要经验是将元数据更新和发布从内容分发中分离出来。LAD 的架构依赖于代理不断接收元数据更新。如果每个代理都接收所有元数据更新，那么请求的数量就会太高。我们通过使用 shards 来解决这个问题：我们没有将整个数据树作为一个分发树的一部分，而是将它分割成较小的分发树，每个分发树都服务于数据树的一部分。
我们实现分片设计的方法是让每个分片位于目录结构中的一个特定点，并递归地包含它下面的所有对象。分片为订阅提供了一个可靠的媒介：它限制了树的总数，同时平衡了每个代理接收的元数据量。
控制平面 (上图左) 是分发者和每个订阅者之间的轻量级的 Thrift RPC。分发服务器使用它来发送树，这些通知父节点与其相关的新子节点，并检查订阅者的活跃度。订阅服务器还使用控制平面向分发服务器发送订阅请求。分发服务器将这些请求映射到该订阅所属的分片，并将订阅服务器添加到分发树中。
数据流平面 (在上图右侧) 是位于分发树对等点间的 Thrift RPC，它任务非常艰巨。父节点用它向子节点发送来自分发服务器的元数据更新。数据流平面也会被用来接收来自子节点的内容请求。
拥有独立的控制和数据流平面后，每个分发服务器可以处理大约 40,000 个订阅者；而 ZooKeeper 只能处理大约 2500 个订阅者。
我们在构建和部署 LAD 时学到了一些有用的经验。以下是一些重点总结:
工具化和可监控对于生产部署至关重要。从经验来看，基于 P2P 的系统在操作和调试方面很具有挑战性，因为不清楚给定请求的发送或接收路径中有哪些节点。
故障提醒和灾备测试在规模上是至关重要的。除了文档化良好的操作过程之外，我们还发现运行一些测试用例及开发策略，有利于在出现问题时有效地做出反应。具体来说，我们运行了一系列测试，引入了各种类型的应用程序、主机、网络和集群级别的故障，以在不影响任何客户机的情况下验证 LAD 的弹性。这是一次令人满意的过程，因为我们发现了程序和工具中的 bug 及不足点。
连续和定期测试对系统的长期可靠性至关重要。仅仅只将上面列出的测试运行一次是不够的，因为在 Facebook 上事情发展变化很快，关于系统或工具的假设可能不会一直成立。我们正在对测试过程进行自动化，以便能够及时发现并处理系统产生的问题。
现在，作为配置管理系统的数据分发框架，LAD 已经被部署到生产环境中。我们也在评估发现其他优秀的大规模内容分发应用程序。
原文来自：
本文地址：//gulass.cn/facebook-lad.html编辑：张建，审核员：逄增宝
本文原创地址：//gulass.cn/facebook-lad.html编辑：张建，审核员：暂无
