标签: scalability

Nginx worker_connections“设置了一个工作进程可以打开的最大并发连接数。这个数字包括所有连接（例如与代理服务器的连接等），而不仅仅是与客户端的连接。另一个考虑因素是实际的同时连接数不能超过当前最大打开文件数限制”。我对此有几个疑问：

1. 为此，最佳或推荐值应该是多少？
2. 使用大量工作连接的缺点是什么？

为了我的求知欲，我试图了解像 Facebook 或 Wikipedia 这样的大型网站是如何运作的。我阅读了构建可扩展站点的各种技术，但我仍然对一个特定的细节感到困惑。

让我困惑的部分是，最终，DNS 会将整个域映射到单个 IP 地址，或者在循环 DNS 的情况下映射到少数 IP 地址。

例如，wikipedia.org 只有一个 A 类 DNS 记录。因此，来自世界各地的访问维基百科的人必须向 DNS 中指定的一个 IP 地址发送请求。

侦听大型站点的 IP 地址的硬件是什么，它如何处理来自世界各地用户请求的所有负载？

编辑 1：感谢所有回复！任播似乎是一个可行的答案......有谁知道一种检查特定 IP 地址是否是任播路由的方法，以便我可以验证这确实是大型站点在实践中使用的技巧？

编辑 2：在对该主题进行更多阅读后，似乎任播通常不用于动态 Web 内容。任播通常用于 UDP（例如，DNS 查找），或有时用于静态内容。

需要注意的一件有趣的事情是 Facebook 使用 profile.ak.fbcdn.net 来托管静态内容，如样式表和 javascript 库。每次 ping 这个名字时，我都会收到来自不同 IP 地址的响应。但是，我不知道这是正在使用的任播还是完全不同的技术。

回到我最初的问题：据我所知，即使是大型站点也会有一个昂贵的负载平衡硬件来监听其少数公共 IP 地址。

我经常在一堆应用服务器前看到带有 SLB/反向代理的 Web 应用架构。

当到SLB的连接数需要太多资源而单个SLB无法有效处理时，会发生什么情况？对于一个具体但过度的示例，请考虑 200 万个持久 HTTP 连接。显然，单个SLB 无法处理此问题。

什么是缩放的建议配置了一个SLB？

创建 LB 的组/集群是典型的吗？如果是这样，客户端负载如何在 LB 组之间分布？

我使用 VMWare 已经很多年了，运行了几十台生产服务器，几乎没有问题。但我从未尝试在单个物理主机上托管 20 多个虚拟机。这是一个想法：

1. 精简版的 Windows XP 可以使用 512MB 的 RAM 和 4GB 的磁盘空间。
2. 5,000 美元为我买了一台 8 核服务器级机器，配备 64GB 内存和四个 SAS 镜像。
3. 由于上面提到的 100 个虚拟机适合这个服务器，我的硬件成本仅为每个虚拟机 50 美元，这非常好（比在 GoDaddy 或任何其他托管商店租用虚拟机便宜）。

我想看看是否有人能够通过 VMWare 实现这种可扩展性？我做了一些测试，遇到了一个奇怪的问题。一旦启动 20 个虚拟机，虚拟机性能就会开始急剧下降。同时，主机服务器没有出现任何资源瓶颈（磁盘空闲 99%，CPU 利用率低于 15%，有足够的空闲 RAM）。

如果您能分享有关扩展 VMWare 或任何其他虚拟化技术的成功案例，我将不胜感激！

我希望你们中的许多人都在使用高流量数据库驱动的网站，并且您的主要可扩展性问题很可能在数据库中。我最近注意到一些事情：

1. 大多数大型数据库需要一个 DBA 团队才能扩展。他们不断与硬盘驱动器的限制作斗争，最终得到非常昂贵的解决方案（SAN 或大型 RAID、用于碎片整理和重新分区的频繁维护窗口等）。维护此类数据库的实际年度成本在 10 万美元到 100 万美元之间对我来说太陡了:)

2. 最后，我们找到了几家公司，如 Intel、Samsung、FusionIO 等，它们刚刚开始销售基于 SLC 闪存技术的速度极快且价格合理的 SSD 硬盘。这些驱动器的随机读/写速度比市场上最好的旋转硬盘快 100 倍（每秒高达 50,000 次随机写入）。它们的寻道时间几乎为零，因此随机 I/O 的成本与顺序 I/O 相同，这对数据库来说非常棒。这些 SSD 驱动器每 GB 的成本约为 10-20 美元，而且它们相对较小（64GB）。

因此，似乎有机会通过简单地构建一个足够大的 RAID 5 SSD 驱动器阵列来避免以传统方式扩展数据库的巨额成本（只需花费几千美元）。然后我们不关心数据库文件是否碎片化，我们可以承受每秒 100 倍的磁盘写入，而不必将数据库分布在 100 个轴上。.

还有人对此感兴趣吗？我一直在测试一些 SSD 驱动器，可以分享我的结果。如果本网站上有人已经用 SSD 解决了他们的 I/O 瓶颈，我很想听听你的战争故事！

附注。我知道有很多昂贵的解决方案可以帮助实现可扩展性，例如久经考验的基于 RAM 的 SAN。我想明确一点，即使 5 万美元对我的项目来说也太贵了。我必须找到一个成本不超过 1 万美元且实施时间不长的解决方案。

戴夫、NXC 和 Burly，

感谢您的回复！我想澄清一下，“便宜”这个词在我的情况下非常重要。因此，我必须使用廉价的戴尔服务器（4K 美元的 2950 年代，只有 8 个内存条）。我已经安装了 32GB 的 RAM，所以我无法继续以这种方式扩展。此外，添加 RAM 并不能使您免于磁盘写入瓶颈，这是我现在的主要问题。

我曾经关心 SSD 的使用寿命，但在阅读了现代磨损均衡算法后，我很确定这些驱动器将持续足够长的时间。我的数据库每天写入 300GB，预计在 2009 年每天会超过 1TB。企业级 SSD 旨在在多年内每天处理大约 10TB 的写入。 …

我想设置 statsd/graphite，以便我可以记录在 HTML 设备上运行的 JS 应用程序（即不在包含的 LAN 环境中，并且可能有大量我无法直接控制的传入数据）。

我的限制：

• 入口点必须说 HTTP：这是通过一个简单的 HTTP-to-UDP-statsd 代理解决的（例如 github 上的 httpstatsd）
• 必须抵抗单个服务器的故障（与墨菲定律作斗争：）
• 必须是水平可扩展的：webscale，宝贝！:)
• 架构应该尽可能简单（和便宜）
• 我的服务器是虚拟机
• 数据文件将存储在文件管理器设备上（使用 NFS）
• 我可以使用 tcp/udp 硬件负载平衡器

总之，数据路径：[client] -(http)-> [http2statsd] -(udp)-> [statsd] -(tcp)-> [graphite] -(nfs)-> [filer]

到目前为止我的发现：

• 扩展 http2statsd 部分很容易（无状态守护进程）
• 缩放 statsd 部分似乎并不简单（我想我最终会在石墨中得到不连贯的值，例如 sum、avg、min、max ...）。除非 HTTP 守护进程进行一致的散列以对密钥进行分片。也许是一个想法......（但接下来是 HA 问题）
• 缩放石墨部分可以通过分片（使用碳继电器）来完成（但这也不能解决 HA 问题）。显然，多个耳语实例不应写入相同的 NFS 文件。
• 缩放文件管理器部分不是问题的一部分（但 IO 越少越好:)
• 扩展 webapp 似乎很明显（虽然我没有测试过），因为它们只读取共享的 NFS 数据

所以我想知道是否有人有经验和最佳实践可以分享一个可靠的 statsd/graphite 部署？

很长一段时间以来，我一直想知道是否有系统必须“纵向扩展”（到更强大、更昂贵的服务器上）而不是通过拆分到许多较小的服务器来“横向扩展”。

这样的系统是否存在，如果存在，是否有什么特别的东西会导致系统需要扩展而不是横向扩展？（例如，可能 ACID-complaint 数据库事务或其他强大的数据完整性要求会产生这种需求。）

由于向上扩展似乎比向外扩展带来更高的硬件成本，因此如果可能的话，这似乎是您想要避免的事情，但我不确定它是否总是可以避免的。

那么，是否存在无法横向扩展而必须纵向扩展的系统？什么可能导致这种情况，您将如何识别这样的系统？（它们通常是否具有一些共同的特征，可能使它们更容易识别？）

在这篇计算机世界文章中，它指定 PostgreSQL 可以扩展到 64 核的限制。这是否意味着一个 64 核的多核处理器？还是内核更少的多个处理器？

我问的原因是因为我试图找出 PostgreSQL 可以扩展到多少处理器，但当然这可能仅限于处理器的类型。但是，我一直在其他数据库中找到其他统计数据（即 Microsoft SQL Server在这里声明它可以扩展到 320 个逻辑处理器），并且他们没有指定它们的核心数。这是一个非常模糊的统计数据吗？

任何想法将不胜感激。谢谢！

我正在尝试以多区域方案扩展我们的 Web 应用程序（PHP、MySQL、memcache）。目前，我们使用的设置在 ELB 和 RDS 实例后面有两个 EC2 实例，它们都在美国东部（弗吉尼亚）地区。

我们也希望在欧盟（爱尔兰）地区开展业务。这意味着那里至少有一个新的 EC2 实例（与其他实例相同，为相同的应用程序提供服务）。

我已经复制了所需的 AMI，设置了新实例，设置了相同的 ELB 配置（SSL 终止所需）并在 Route53 中配置了基于延迟的路由。它按建议工作。

但是，来自欧盟的客户存在速度问题。这是因为欧盟 EC2 实例连接到美国的 RDS 实例。据我所知亚马逊还没有启用RDS多区域复制。

您对如何在使用单个 RDS 实例时正确加速整个设置有什么建议吗？

另外，关于如何扩大规模的任何想法？理想情况下，出于各种原因，我们希望继续使用 RDS 技术。尽管如此，我愿意接受建议（我猜下一个想法是托管我们自己的 MySQL 服务器）。

我有一个网站，可以存储用户个人资料图片。每个图像都存储在用户特定的目录 (Linux) 中。目前我有 30 多个客户群，这意味着我将拥有 30 多个文件夹。但是我当前的 Linux 机器（ext2/ext3）不支持创建超过 32000 个目录。我该如何度过这一关？即使是 YouTube 的人也有同样的问题，视频缩略图。但是他们通过迁移到 ReiserFS 解决了这个问题。我们不能有更好的解决方案吗？

更新：当在 IRC 中询问时，人们询问是否将其升级到 ext4，它有 64k 的限制，当然你甚至可以通过它。或者内核黑客来改变限制。

更新：如何根据用户 ID 范围将用户群拆分为文件夹。意思是一个文件夹中的 1-1000，另一个文件夹中的 1000-2000。这似乎很简单。你说呢，伙计们？

坦白说，就没有其他办法吗？