.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》（ http://mysqlha.blogspot.com/）。