来自 Dropbox 的可扩展性设计经验

作者：Rajiv Eranki
出处：http://eranki.tumblr.com/post/27076431887/scaling-lessons-learned-at-dropbox-part-1

来自Dropbox的可扩展性设计经验

摘要：本文作者曾负责Dropbox的扩展性工作，经历了用户数从4,000到40,000,000的激增。在那段难忘的时光里，作者和他的三名同事共同工作在后端。本文作者就扩展性，尤其是在一个资源受限的快速增长环境中处理问题的心得。

导读：本文作者曾负责Dropbox的扩展性工作，经历了用户数从4,000到40,000,000的激增。在那段难忘的时光里，作者和他的三名同事共同工作在后端。本文作者就扩展性，尤其是在一个资源受限的快速增长环境中处理问题的心得。

我们经常使用的一种技术就是人工模拟站点的负荷。例如，我们经常模拟大量的超过常规的缓存读取。一旦缓存出现故障，我们可以快速地切换重复查询，并为提出解决方案赢得时间。为什么不未雨绸缪呢？这是因为许多故障是突然的，我们几乎无法检测到。

这种解决方案并不完美。我们只是模拟了高负荷的读操作，大量的读负载可能会导致出现意外的问题，写负载又很难模拟（数据风险，索争用的问题）。但通过我们的经验，额外的读取操作已经足够赢得时间了。

以图表展现性能指标

通过数以万计的服务器图形处理器聚合的自定义数据图表变得越来越有用。现成的监控解决方案并不能处理这种类型的负载，我们想以行的方式添加数据，作为我们的统计方法。

我们采用memcached、crom和ganglia的组合实现了我们的监控解决方案。我们希望将所有发生的事件都以图形的方式表现出来，每次事件都会存储在本地线程的内存缓冲区中。每秒钟，我们都会将数据汇集到缓存中；每分钟，我们都会将数据汇集到中央服务器上，并提交ganglia处理。这非常具有扩展性，使得我们可以实时处理数以千计的状态数据。

下面是一个汇总图表的示例：

折线代表站点的平均响应时间，每段代表工作的时间间隔。大约1点左右，折线有一个波峰，这是MySQL提交造成的。我们的图形数据还可以体现更多的信息，这便于我们直观地发现问题。

用Bash进行数据分析

也许你还没有使用Shell，不太了解Shell是如何快速执行任务（借助Perl这样的编程语言）。比如说，我们想监控Web服务器。但是Web服务器的日志相当庞大，以分钟为单位的日志检索不能提供足够的细粒度。

Apr 8 2012 14:33:59 POST ... Apr 8 2012 14:34:00 GET ... Apr 8 2012 14:34:00 GET ... Apr 8 2012 14:34:01 POST ...

我们可以这样运用Shell：

cut -d ' ' -f1-4 log.txt | xargs -L1 -I_ date +%s -d_ | uniq -c | (echo "plot '-' using 2:1 with lines"; cat) | gnuplot

我们很快就会得到运行状态的漂亮图表，而且非常易于定制。如果你不熟悉命令行工具，推荐你了解一下以下命令：

sed,awk,grep,cut,head,tail,sort,uniq,tr,date,xargs

垃圾日志也有它的用处

垃圾日志并非全无作用。虽然我们非常讨厌冗繁、庞杂的日志，但这也许是跟踪代码的方式。所以当我删除很长一段时间间隔的日志之后，当我发现它的价值，也曾倍感后悔。

故障转移测试

如果有失败的可能性，那么就要对故障转移进行测试。进行故障转移时请注意：

从上次故障转移群集之后增加的负载可能会导致这次故障转移群集的级联效应；从上次故障转移群集之后增加的脚本可能需要旧的依赖资源才能正常运行。

最后在故障未发生之前进行故障转移测试，这就像消防演练一样。

保持同质化的重要性

保持同质化对数据非常重要。我曾经有两个用户数据切片，随着它们的增长，我需要以新的数据切片予以替代，但令人头疼的是，它们的增长速度并不相同。

同质化对于硬件也同样非常重要，这可以简化容量规划。最佳的方式就是保持尽可能少的服务器类型。

保留停机日志

每次站点关闭，都要记录好停机的时间，并将故障原因标注清楚。日后，我们可以根据记录进行分析，提出更好的应对方案，以尽可能减少停机时间。

UTC

让一切运行在UTC之下。保证服务器与数据库遵循UTC时间，可以了却许多令我们头疼的问题。

我们使用的技术

我们采用了如下软件技术：

1.Python/C

2.MySQL

3.Paster/Pylons/Cheetah（Web框架）

4.S3/EC2用于文件存储

5.服务器前端和服务器间协调处理采用缓存技术

6.Ganglia用作图形处理

7.Nginx作为前端服务器

8.Haproxy在Nginx之后为应用服务器提供负载均衡

9.Nagios作为内部安全监控

10.Pingdom作为外部服务监控

11.GeoIP映射IP地址

以上选择都遵循了相同的原则，简单可靠。选择MySQL而不选择PostgreSQL，是因为当时PostgreSQL对复制的支持并不够好，而且在网络上来自MySQL的社区支持也更强大，谷歌、雅虎和Facebook都为MySQL写过补丁。

我们使用SQLAlchemy作为自己的ORM。其实我个人很讨厌ORM，因为它们总是会引发错误。使用它们并不必要，MySQL的性能坚如磐石。

使用之前先进行模拟分析

后端工程相当庞大复杂，对于不同的产品，我们想发挥它们的优势。所以，在实施之前，一定要进行模拟测试。

安全与便捷的权衡

安全非常重要，因为Dropbox保存了每个人的私人文档。服务各不相同，安全设置会影响到每个人，程序员或普通用户。

例如，几乎任何网站登录时都会提示输入用户名和密码，但如果输入错误，它会提示错误，但不会告诉我们具体是哪一个。这是一个很好的安全策略，但如果作为用户忘记了是使用哪一个用户名注册的网站，也许会因此如坐针毡。（张志平/编译）

原文链接：Scaling lessons learned at Dropbox, part 1