Facebook技术总监：如何管理10亿用户的数据？
程序员文章站
2022-05-05 12:12:15
...
Facebook用户数量，已经突破10亿大关。Facebook在发展期间，所实现的技术成就，成为了IT行业工程师关注的话题。究竟Facebook取得了哪些技术成就呢？Facebook前工程部门总监，在问答网站Quora上，对这一问题作出回答。无论对于IT行业的投资者还是使用者，这些回答都有着指导意义。
以下是文章全文：
我在Facebook的基础架构软件开发团队，工作了5年，并且参与了多数项目的开发。我认为在Facebook时，最伟大的成就是Memcache/MySQL集群。一年前，我离开Facebook的时候，这个集群中已经拥有超过1万亿对象（没错是万亿），每秒请求数量超过10亿，处理时间通常不超过1毫秒。这一集群，在多个数据中心之间，保持了良好的一致性，并且很少出现停机的情况。
实际上，我们取得的真正成就，与Memcache和MySQL并没有多大的关系——随着时间的推移，这些都将会被新的“技术”所取代，但是这里真正重要的技术，是让数量如此庞大的机器，快速、可靠的协同工作。这并不同于通常意义上，人们在询问“你用的是什么样的技术？”时，所指代的东西，但是这一方面确实会出现很多有趣的创新。
这包括算法方面的技巧，如分片（Shard）、分区（Partition）、缓存数据，以及保持分布式数据的一致等。虽然像“部署和监控”这样的事情，听上去似乎有些很普通，但是当一切到了Facebook这样大的规模，就变的不再简单。
以下是我们面临的一些具体的挑战：
1. 数据中心间的一致性
Facebook是一个实时的应用程序，这也就意味着，无论世界哪一个角落的数据发生改变，都需要立即显示到所有其他的地方。因此这对一致性有着令人惊讶的高要求。
常常有人说，“哦，Facebook只是一个让人觉得挺有趣的社交网站，一致性并没有那么重要。”但是如果信息出现的时间顺序有问题，或者有的消息会凭空消失，那么这些情况就很容易惹恼用户。以下是我们在2007年，创建首个地理分布数据中心时的老博客：《Scaling Out Facebook》
现在回头看，虽然这个方案听起来有些严格，但是它真的很有用，而且帮助让我们达到了现在这个巨大得规模。而现在的设置显然已经变得更为复杂。
2. 网络流
Facebook的页面，需要很多小块的数据，而这些往往并不容易聚集。所以我们经常看到的一个模式，是一台服务器，会从大量其他的服务器处，要求大量小的对象。而这里的问题在于，如果所有的服务器都在同时进行回复，你就会通过请求服务器的rack switch和网络适配器（NIC）突然获得大量的数据包，然后就会有数据包被丢弃。这就是学术文献中所谓的“TCP incast”，而我们解决这个的方法，是对机器上发送的请求进行截流。
而当故障（failure）出现的时候，网络问题往往会变得更加糟糕。大多数软件在没有从另一个服务器获得回应时，都会重新发送另外一个数据包。不幸的是，大多数时候，没有获得回复的原因，恰恰是另外一个服务器已经过载。因此，当一个服务器过载严重，而无法作出及时回复时由于大量请求会重新发送，它的数据流量会瞬时增长一倍。
我们投入了大量的时间用于算法研究，并希望无缝处理“重试”（retry）可以解决的小问题，但是也需要确保不会在出现大故障的时候失去控制，因为那时候重试只会让事情变得更糟。
3. 高速缓存配置
这里有很多东西需要平衡——如果你有大的对象，你希望通过机器进行传递开，这样你就可以进行并行处理；但是如果是小的对象，你则希望它们可以同时出现，这样在RPC调用会给你带来多个对象。而Facebook需要的往往是后者，因此我们在改善“每RPC对象数量”方面，使用了很多的技巧。
很多情况都需要分离不同工作负载的对象，进行不同的调整。我们还花了大量的的时间，搞清楚是什么内存之中最具有成本效益的东西，以及何时非规范化能有用（实践中的大多数时候，非规范化并没有什么实质性的帮助）。
4. 失败处理
正如前面网络部分所提到的，有的时候一些方法能够解决小问题，但往往会让大问题变得更糟。例如，我有一个算法，给随机服务器发送请求，如果它没有得到答复，就会把请求重新发送到另一个不同的随机服务器上，直到它得到一个答复才会停止。如果你只有一两个机器出现问题的时候，这种方法显然会表现很好。但是如果你一半的机器都出现问题，那么就成了一场灾难。
这时，所有其他的机器的负荷都会突然加倍，而如果一半的机器都出现问题，很有可能意味着有着负载已经过高。这时候，你需要做的事情，是检测过载情况，并且减少负载。重要的是，要记住计算机科学意义上的实时系统，意味着：一个迟到的回应，就是一个错误的回应。
放弃一个请求的时候，人们往往会感觉不好，不过这往往是最好的处理方式——在出现问题的时候，最大化正确答案的数量才是最正确的。
另一种常见的模式是，当有些东西变慢的时候，就建立一个较大的队列（queue），然后让所有事情慢下来，减少负载。这可以是一个很棘手的算法，因为你可能在正常操作中也需要一个深队列，来处理瞬间突发流量。
5. 提升Memcache和MySQL
我们讨论到数据库／缓存集群的时候，人们总会想到Memecache和MySQL。我们在Memcache方面做了大量的工作，以提升吞吐量——大量的分析和解决方法，这大多数都是在网络栈中。因此很多这样的工作，实际上是在Linux内核中发生的。
在MySQL中，则是关于以一种合理的方式，获得磁盘上的数据，并且把内存中最有用的东西放到缓存里。马克•卡拉汉（Mark Callaghan）的博客中，有着大量的信息：《高可用性MySQL》。
6. Meta
我们所遵循的原则，可以看看这篇文章《让Facebook的用户超过5亿》
以下是文章全文：
我在Facebook的基础架构软件开发团队，工作了5年，并且参与了多数项目的开发。我认为在Facebook时，最伟大的成就是Memcache/MySQL集群。一年前，我离开Facebook的时候，这个集群中已经拥有超过1万亿对象（没错是万亿），每秒请求数量超过10亿，处理时间通常不超过1毫秒。这一集群，在多个数据中心之间，保持了良好的一致性，并且很少出现停机的情况。
实际上，我们取得的真正成就，与Memcache和MySQL并没有多大的关系——随着时间的推移，这些都将会被新的“技术”所取代，但是这里真正重要的技术，是让数量如此庞大的机器，快速、可靠的协同工作。这并不同于通常意义上，人们在询问“你用的是什么样的技术？”时，所指代的东西，但是这一方面确实会出现很多有趣的创新。
这包括算法方面的技巧，如分片（Shard）、分区（Partition）、缓存数据，以及保持分布式数据的一致等。虽然像“部署和监控”这样的事情，听上去似乎有些很普通，但是当一切到了Facebook这样大的规模，就变的不再简单。
以下是我们面临的一些具体的挑战：
1. 数据中心间的一致性
Facebook是一个实时的应用程序，这也就意味着，无论世界哪一个角落的数据发生改变，都需要立即显示到所有其他的地方。因此这对一致性有着令人惊讶的高要求。
常常有人说，“哦，Facebook只是一个让人觉得挺有趣的社交网站，一致性并没有那么重要。”但是如果信息出现的时间顺序有问题，或者有的消息会凭空消失，那么这些情况就很容易惹恼用户。以下是我们在2007年，创建首个地理分布数据中心时的老博客：《Scaling Out Facebook》
现在回头看，虽然这个方案听起来有些严格，但是它真的很有用，而且帮助让我们达到了现在这个巨大得规模。而现在的设置显然已经变得更为复杂。
2. 网络流
Facebook的页面，需要很多小块的数据，而这些往往并不容易聚集。所以我们经常看到的一个模式，是一台服务器，会从大量其他的服务器处，要求大量小的对象。而这里的问题在于，如果所有的服务器都在同时进行回复，你就会通过请求服务器的rack switch和网络适配器（NIC）突然获得大量的数据包，然后就会有数据包被丢弃。这就是学术文献中所谓的“TCP incast”，而我们解决这个的方法，是对机器上发送的请求进行截流。
而当故障（failure）出现的时候，网络问题往往会变得更加糟糕。大多数软件在没有从另一个服务器获得回应时，都会重新发送另外一个数据包。不幸的是，大多数时候，没有获得回复的原因，恰恰是另外一个服务器已经过载。因此，当一个服务器过载严重，而无法作出及时回复时由于大量请求会重新发送，它的数据流量会瞬时增长一倍。
我们投入了大量的时间用于算法研究，并希望无缝处理“重试”（retry）可以解决的小问题，但是也需要确保不会在出现大故障的时候失去控制，因为那时候重试只会让事情变得更糟。
3. 高速缓存配置
这里有很多东西需要平衡——如果你有大的对象，你希望通过机器进行传递开，这样你就可以进行并行处理；但是如果是小的对象，你则希望它们可以同时出现，这样在RPC调用会给你带来多个对象。而Facebook需要的往往是后者，因此我们在改善“每RPC对象数量”方面，使用了很多的技巧。
很多情况都需要分离不同工作负载的对象，进行不同的调整。我们还花了大量的的时间，搞清楚是什么内存之中最具有成本效益的东西，以及何时非规范化能有用（实践中的大多数时候，非规范化并没有什么实质性的帮助）。
4. 失败处理
正如前面网络部分所提到的，有的时候一些方法能够解决小问题，但往往会让大问题变得更糟。例如，我有一个算法，给随机服务器发送请求，如果它没有得到答复，就会把请求重新发送到另一个不同的随机服务器上，直到它得到一个答复才会停止。如果你只有一两个机器出现问题的时候，这种方法显然会表现很好。但是如果你一半的机器都出现问题，那么就成了一场灾难。
这时，所有其他的机器的负荷都会突然加倍，而如果一半的机器都出现问题，很有可能意味着有着负载已经过高。这时候，你需要做的事情，是检测过载情况，并且减少负载。重要的是，要记住计算机科学意义上的实时系统，意味着：一个迟到的回应，就是一个错误的回应。
放弃一个请求的时候，人们往往会感觉不好，不过这往往是最好的处理方式——在出现问题的时候，最大化正确答案的数量才是最正确的。
另一种常见的模式是，当有些东西变慢的时候，就建立一个较大的队列（queue），然后让所有事情慢下来，减少负载。这可以是一个很棘手的算法，因为你可能在正常操作中也需要一个深队列，来处理瞬间突发流量。
5. 提升Memcache和MySQL
我们讨论到数据库／缓存集群的时候，人们总会想到Memecache和MySQL。我们在Memcache方面做了大量的工作，以提升吞吐量——大量的分析和解决方法，这大多数都是在网络栈中。因此很多这样的工作，实际上是在Linux内核中发生的。
在MySQL中，则是关于以一种合理的方式，获得磁盘上的数据，并且把内存中最有用的东西放到缓存里。马克•卡拉汉（Mark Callaghan）的博客中，有着大量的信息：《高可用性MySQL》。
6. Meta
我们所遵循的原则，可以看看这篇文章《让Facebook的用户超过5亿》