让我们来看看现在学习的产物：Flickr 和LAMP

　　最近其实发现了不少可以和大家一起学习的好内容。Flickr 的 John Allspaw 在 MySQL Conf 2007 作了一个题为 Capacity planning for LAMP (下载PDF文件) 的技术报告，说起容量规划，多少有点空对空的意思，不过这个 PPT 还是介绍了不少 Flickr 的网站运维经验。

　　Flickr 的数据量的确越来越惊人了，根据文档中透漏的数据：

　　Squid Cache 中共有 3500 万张图片;

　　在 Squid RAM 中有 200 万张图片;

　　4.7亿的图片，每张图片有4到5种尺寸;

　　每秒钟 38000 个到 memcached 的请求;

　　2 PB 裸存储容量(周日需要消耗1.5T 的空间)

　　三个主要步骤：

　　计划

　　基于实际业务，而不是抽象的理论。John Allspaw 认为基准测试(Benchmark) 作用并不大，这一点我也很赞同。在业务频繁变化的环境中，Benchmark 根本不能与实际业务情况匹配。

　　部署

　　Flickr 使用SystemImager/SystemConfigurator(自动化安装、软件分发)，CVSup(网络中的文件分发、更新)，Subcon(配置管理工具)提高部署效率。

　　度量(图形化展现)

　　Flickr 使用了 Ganglia 来进行容量数据的展现。Ganglia 最初设计是用于高性能集群计算的监控上面，也是以 RRDTool 为基础来进行图形展示。Ganglia 最主要的优点还是管理的方便性: Client/Server 结构, 各自跑 Demon 进行数据交互(XML形式)。相比起来， Cacti + Collectd 需要进行很多手工配置，在面对大量需要监控的主机的时候的确不那么方便。

　　Web 2.0 站点的运维似乎大家都在摸索着走。期望这次阿里巴巴组织的侠客行大会上也有有朋友坐下来聊聊这个话题(Flickr 的架构师本来可以来的，因为时间的问题不能成行，挺遗憾的)。

通过文章，我们学习到了不少关于LAMP和Flickr方面的知识，希望大家喜欢！

【编辑推荐】

1. Redhat Linux AS4下的LAMP与Discuz装置
2. lamp solutions
3. LAMP的安装和配置讲解
4. node.js、MongoDB下一代的LAMP
5. 确保安全使用LAMP开源开发工具的四步曲
6. Linux将继续留在LAMP中
7. 当开源LAMP遭遇WindowsAMP