缩放LAMP堆栈

现在硬件如此便宜，越来越less的人甚至到了需要多台机器的地步。 $ 10,000将会购买你：

• 内存16-32GB;
• 2个四核心Xeon;
• RAID5磁盘arrays。

这种机器可以在一个甚至适度优化的网站上为超过10,000个并发用户提供服务，除了资源最为密集的应用程序之外。

基本上有两种可伸缩性的方法：

• 垂直：基本上购买最大的机器，所以你不需要超过一个;
• 横向：以适合平行的方式做事。 只需要最密集的应用程序。

看看StackOverflow：它基本上运行在一台Web服务器和一台数据库服务器上，每个月的浏览量超过600万次。

这就是说，可扩展性是关于寻找和解决你的瓶颈。

• 如果你的数据库正在放慢速度，或者给它更多的资源，或者使用某种forms的内存caching来减轻负载;
• 如果磁盘I / O是你的问题，那么同样适用;
• 如果内存不足导致页面错误太多，从而导致磁盘I / O问题，请添加更多的内存;
• 您的应用程序和数据是否适合跨服务器参与？ 如果是这样的话，这是横向扩展的一种方式。
• 如果带宽是一个问题，而且你提交大文件，那么CDN可能就是答案。
• 等等。

不过最终，10万点击/月并不是那么大。 我怀疑现在在一个典型的网站上，如果你没有做错事情，那么在你遇到真正的问题之前，你需要超过1000万个/月（例如，如果你没有索引你的数据库search，那么当然你会有这个问题，但他们与点击/月无关）。

我会说冗余比可扩展性更令人头痛。 冗余链接，系统故障监控stream程，拥有和维护DR（灾难恢复）站点，处理需要解决的问题（如裂脑群集）等问题远远更加困难和繁琐。

使用清漆或鱿鱼 。 两者都是networking加速器，并且都非常适合静态媒体文件。

如果向外扩展，您甚至可以拥有一台用于网页caching的机器和一台用于dynamic内容的机器

或者，你可以尝试使用mods来调整apache： mod_expires ， mod_headers ， mod_cache ， mod_file_cache ， mod_mem_cache 。

取决于处理你的数据库 – 如果你正在提供静态内容或接近静态内容， 你将通过非常适中的硬件扩展到超过100K /月。

复杂的数据库驱动的网站，如论坛可能是一个更大的问题，你需要考虑数据库复制，主网站上的反向代理作为额外的caching，以及额外的负载平衡的networking服务器。 大多数“重型”数据库使用软件还支持诸如memcached之类的东西，可用于减less常见请求上的数据库负载。

坦率地说，我认为你现在可能高估了需求–100K在一台机器上处理就好了。 一旦你打破了10M，那么你需要看看更复杂的解决scheme，比如上面列出的解决scheme。

我个人的build议是，总是希望平行机器比单复杂的机器更好 – 不仅价格便宜，而且在时间到了的时候，还有更多的空间。 扩展已经很昂贵的硬件可以让你进入25000美元的服务器领域，在那里“爆炸性的”崩溃。

一旦你移动超过10万次点击/月

没什么！！！ 如果你遇到麻烦，每月点击10万次，你会遇到麻烦。 一般来说，你应该不会遇到每天服务100K的最笨的系统的问题。

这是关于LAMP …和CMS系统

我的原地：静态媒体（audio/video/图像）从S3 / CDN的服务吨

有很好的Web服务器用于这些目的：lighttpd – 它服务YouTuble媒体stream，Nginx也不错。

这些是轻量级的Web服务器，在高负载下可以很好地扩展。

即使将Apache模块从mod-prefork切换到mod-worker也会有所帮助（即使lighttpd仍然更好）。

底线：这些负荷远不是很高。

其他人指出，100K点击并不是一个问题，虽然我怀疑他们错过了你已经提供了许多点击没有问题的观点…

鉴于你的内容包括video，我build议networking带宽将是你的第一个问题，一旦你有足够的并发请求大型对象的I / O请求。 如果你的内存比数据更多，那么一旦所有东西都放在caching中，I / O将不会成为问题（尽pipe在任何服务器closures之后，需要一些时间来填充caching）。

有一件事情，你必须指定在这样的尺寸要求是什么分配你的命中。 他们平均分布在一个月或更多突发？ 举例来说，一个收集国家彩票信息的网站可能会在抽奖时间后的两个小时内看到其每周stream量的80％或更多 – 两小时内10万个请求中的80％是每秒2.7（假设为4周的一个月）仍然不是很大，但取决于大小/复杂性或响应。 其他不太可预测的突发也是可能的，例如，如果您的网站上的video触及Digg的头版或类似内容会发生什么情况。

最大的障碍可能是

• 让您的应用程序形成一个松散耦合的体系结构，从而降低ACID和其他强大的限制，以允许asynchronous操作和短期不一致性。 请参阅布鲁尔的CAP定理以获得对此主题的广泛概述。

• 处理多个节点的正确pipe理。 这包括基本的系统pipe理任务，如软件包pipe理以及testing和推出更改请求。 当你有50个networking服务器，你不能只是“重新启动所有的Apache服务器”; 有一些想法必须被纳入这些任务

• 这使我想到了我的最后一点 – 了解在大型系统中可以看到的效果。 雷霆群雄是你将要看到的事情之一。 这篇关于Audiogalaxy的文章也描述了大系统的一些问题。

可扩展的互联网体系结构和容量规划的艺术是关于这个话题的两本书，我可以热烈推荐。

我是一个缩小规模的人，我有一条规则：总是让自己select一个性能问题。

任何无法通过花钱来解决的问题都没有固定的时间来解决，因此总是试图编写/解决问题的方法，但总是让自己select核心/周期/内存/存储/带宽/无论在这个问题上 – 他们总是可以FedEx'ed 🙂

一旦你的点击次数超过10万次，这个社区的人会说什么是最大的障碍？

过度思考问题，过度devise平台，以及使系统复杂化。

100k /月没什么 。 在这一点上，你的整个目标应该花尽可能less的时间，尽可能地集中注意力。