一旦每月点击量超过 10 万次，这个社区的人们会认为最大的障碍是什么？
我的情况：大量静态媒体（音频/视频/图像）由 S3/CDN 提供，但作为备份存储在本地（但不提供）。所有可以缓存的内容都会被缓存，内存约为 8GB，可扩展至 32GB。
我们目前正在处理大约 10 万次点击，没有任何问题，并且很想知道其他人遇到了什么问题：负载平衡？内存问题？磁盘 i/o？
谢谢大家的建议。我查看了相关问题，他们给出了很好的答案，但我只是想得到更多反馈。
答案1
如今硬件如此便宜，越来越少的人需要多台机器。 10,000 美元可以为您购买：
- 16-32GB RAM；
- 2 个四核 Xeon；
- RAID5磁盘阵列。
这种机器可以为除资源最密集的应用程序之外的所有经过轻度优化的站点上的超过 10,000 名并发用户提供服务。
基本上，有两种实现可扩展性的方法：
- 垂直的：基本上购买你能买到的最大的机器，这样你就不需要多台了；
- 水平的：以适合并行的方式处理事务。只有在最密集的应用程序上才需要。
看看 StackOverflow：它基本上在 Web 服务器和数据库服务器上运行，每月点击量超过 600 万次。
话虽如此，可扩展性就是找到并解决瓶颈。
- 如果您的数据库速度变慢，请为其提供更多资源或使用某种形式的内存缓存来减轻负载；
- 如果磁盘 I/O 是您的问题，那么同样的情况也适用；
- 如果内存不足，导致过多的页面错误，从而引起磁盘 I/O 问题，请添加更多内存；
- 您的应用程序及其数据是否适合跨服务器分区？如果是，这就是水平扩展的一种方法；
- 如果带宽是一个问题，并且您正在传输大文件，那么也许 CDN 就是答案；
- 等等。
但归根结底，每月 10 万次点击量并不算多。我怀疑，如今在一个典型的网站上，你需要每月点击量超过 1000 万次才会遇到真正的问题，前提是你做得还不错（例如，如果你没有索引你的数据库搜索，那么你当然会遇到问题，但这些问题与每月点击量无关）。
我想说冗余比可扩展性更令人头疼。拥有冗余链接、监控系统故障进程、建立和维护 DR（灾难恢复）站点、处理相关问题（如裂脑集群）等问题要困难和繁琐得多。
答案2
使用漆或者乌贼。两者都是网络加速器，并且都非常适合静态媒体文件。
如果进行扩展，甚至可以有 1 台机器用于 Web 缓存，1 台机器用于动态内容
或者，您可以尝试使用 mods 来调整 apache： mod_expires，mod_headers，mod_cache，mod_file_cache，修改缓存。
答案3
有点取决于您正在处理什么样的数据库 - 如果您正在提供静态内容或接近静态的内容；您将使用非常适中的硬件扩展到超过 100K/月。
复杂的数据库驱动网站（如论坛）可能是一个更大的问题，您需要研究数据库复制、主网站上的反向代理作为附加缓存以及附加负载平衡网络服务器。大多数“重度”使用数据库的软件还支持诸如 memcached 之类的东西，可用于减少常见请求对数据库的负载。
不过坦白说，我认为你现在可能高估了需求——100K 在单台机器上处理得很好。一旦突破 10M，你就需要考虑更复杂的解决方案，比如我上面概述的那些。
我个人的建议是始终优先使用并行机器，而不是单一的复杂机器——这不仅最终会更便宜，而且在需要时会给你更多的发展空间。扩展已经很昂贵的硬件会让你进入 25,000 美元的服务器领域——这时“物有所值”就不复存在了。
答案4
其他人指出 10 万次点击不是问题，但我怀疑他们错过了你的观点，即已经毫无问题地提供如此多的点击......
鉴于您的内容包括视频，我认为网络带宽将是您的首要问题，其次是 I/O 请求（一旦您有足够多的并发请求用于大型对象）。如果您的 RAM 多于数据，那么一旦所有内容都存储在缓存中，I/O 问题就不大了（尽管在任何服务器关闭后，都需要一段时间才能准备好缓存）。
在尝试确定此类需求的大小时，您必须指定的一件事是您的点击量分布情况。它们是均匀分布在一个月内还是更具突发性？例如，托管有关国家彩票信息的网站可能会在开奖时间后的两小时内看到其每周流量的 80% 或更多 - 两小时内 100K 个请求中的 80% 是每秒 2.7 个（假设一个月有 4 周），这仍然不是很大，但取决于大小/复杂性或响应。其他不太可预测的突发事件也是可能的，例如，如果您网站上的视频登上 Digg 或类似网站的首页，会发生什么情况。