对 Web 层进行分片（原文如此！）以防止负载均衡器瓶颈？

Question

无法完全无状态的大型网站如何在Web层实现极致的可扩展性？

像 eBay 和 Amazon 这样的网站不可能是完全无状态的，因为它们有购物车或类似的东西。将购物车中的每一项都编码到 URL 中是不可行的，将每一项都编码到 Cookie 中并在每次连接时发送它也是不可行的。因此，亚马逊只是将会话 ID 存储到正在发送的 cookie 中。所以我明白 eBay 和 Amazon 的 Web 层的可扩展性应该比 google 搜索引擎的可扩展性难得多，谷歌搜索引擎的所有内容都可以被编码到 URL 中。

另一方面，eBay 和亚马逊的规模都非常巨大。有传言称 eBay 上有大约 15000 个 J2EE 应用程序服务器。

这些网站如何处理这两个问题：极端的可扩展性和状态性？由于站点是有状态的，因此进行简单的 DNS 平衡是不可行的。因此，人们会假设这些公司拥有基于硬件的负载均衡器，例如 BigIP、Netscaler 或类似的东西，它是该站点的单个 IP 地址背后的唯一设备。该负载均衡器将解密 SSL（如果已编码）、检查 cookie 并根据该 cookie 的会话 ID 决定哪个应用程序服务器保存该客户的会话。

但这是不可能的，因为没有一个负载均衡器可以处理数千个应用程序服务器的负载？我想即使这些硬件负载均衡器也无法扩展到这样的水平。

此外，负载平衡对于用户来说是透明的，即用户不会被转发到不同的地址，但仍然始终集中在 www.amazon.com 上。

所以我的问题是：是否有一些特殊的技巧可以实现诸如 Web 层（而不是通常所做的数据库层）的透明分片之类的功能？只要不检查 cookie，就无法知道哪个应用程序服务器正在保存此会话。

编辑： 我意识到，如果需要对网站进行蜘蛛抓取和添加书签，则只需要透明度。例如。如果该网站只是一个 Web 应用程序，例如飞机或火车票预订系统，那么只需将用户重定向到不同 url 后面的特定 Web 服务器集群应该没有问题，例如a17.ticketreservation.com。在这种特定情况下，仅使用多个应用程序服务器集群是可行的，每个集群都位于自己的负载平衡器后面。有趣的是，我没有找到使用这种概念的网站。编辑： 我发现了这个概念 讨论过 在 highscalability.com, ，其中讨论引用了朱雷的一篇文章，名为 “Web 2.0 应用程序的客户端负载平衡”. 。Lei Zhu 使用跨脚本透明地进行客户端负载平衡。

即使存在缺点，如书签、xss 等，我确实认为这对于某些特殊情况来说听起来是一个非常好的主意，即几乎无内容的 Web 应用程序，不需要被蜘蛛抓取或添加书签（例如门票预订系统或类似的系统）。那么就不需要透明地进行负载平衡。

可能有一个从主站点到服务器的简单重定向，例如从 www.ticketreservation.com 重定向到 a17.ticketreservation.com。从那时起，用户停留在服务器a17上。a17本身并不是一个服务器，而是一个集群，通过它可以实现冗余。

初始重定向服务器本身可以是负载均衡器后面的集群。这样，就可以实现真正高的可扩展性，因为 www 后面的主负载均衡器仅在每个会话开始时被命中一次。

当然，重定向到不同的 URL 看起来非常令人讨厌，但是对于单纯的 Web 应用程序（无论如何都不需要进行蜘蛛抓取、深度链接或深度书签），这对用户来说应该只是一个视觉问题？

重定向集群可以轮询应用程序集群的负载并相应地调整重定向，从而实现平衡而不仅仅是负载分配。

Answer 1

易。无状态的Web服务器是负载平衡的。保存会话数据的应用程序服务器（中间层）不是。 Web服务器可以使用您的会话ID cookie来确定要联系的应用服务器。

Memcached和微软的Velocity是解决这一需求的产品。

编辑：网络服务器如何知道要联系哪个应用服务器？这嵌入到会话ID哈希中，一般情况下可以随意完成。它可以像你的会话ID一样简单就是服务器：guid。但是， Memcached 基于哈希值。

重要的是，客户必须能够找出以无状态方式联系的应用服务器。最简单的方法是将其嵌入到密钥中，尽管注册表（可能在它自己的层上）也能正常工作并且可以提供一些容错功能。

编辑2：回到一些易趣采访，我可能已经获得了他们的详细信息实施有点不对劲。他们不做缓存，他们不在中间层做状态。他们所做的是拥有按功能划分的负载平衡中间层（app服务器）。因此，他们将拥有一个服务器池，例如，查看项目。然后是另一个用于销售物品的游泳池。

这些应用服务器具有“智能”功能。路由到分片数据库的DAL（按功能和数据分区，因此Database1上的用户A-L，Database2上的用户M-Z，Items1上的项目1-10000等）。

他们在中间层没有状态，因为它们是按功能划分的。因此，正常的用户体验将涉及超过1个应用服务器池。假设您查看某个项目（ViewAppServerPool），然后对项目（BidAppServerPool）进行投标。所有这些应用服务器都必须保持同步，然后需要分布式缓存来管理所有内容。但是，它们的规模如此之大，以至于没有分布式缓存可以有效地管理它，单个数据库服务器也不能。这意味着他们必须对数据层进行分片，并且任何缓存实现都必须在相同的边界上进行分割。

这与我上面发布的类似，只是向下移动了一层。应用服务器不是让Web服务器确定要联系哪个应用服务器，而是确定要联系哪个数据库。只有在Ebay的情况下，由于它们的分区策略，它实际上可能会击中20多个数据库服务器。但是，同样，无状态层具有某种用于联系有状态层的规则。然而，Ebay的规则比简单化的“User1在Server10上”更复杂一些。我上面解释的规则。

Answer 2

您可能会发现以下文章非常有用，该文件介绍了高可用性键值存储系统的设计和实现，亚马逊的一些核心服务使用这些系统来提供始终在线的＆＃8220;永远在线的服务。经验：

Giuseppe DeCandia，Deniz Hastorun，Madan Jampani，Gunavardhan Kakulapati，Avinash Lakshman，Alex Pilchin，Swami Sivasubramanian，Peter Vosshall和Werner Vogels ，＆＃8220; Dynamo：亚马逊高度可用的键值商店 ＆＃8221;，在”会议录“中第21届ACM操作系统原理研讨会，华盛顿史蒂文森，2007年10月。

Answer 3

您可能必须在其中一个地方的工程团队中确定无疑，但有些人已经从两个地方的谈话和其他信息中做出了有根据的猜测：

易趣架构和亚马逊架构

在当今世界中，只有一个负载均衡器本身就相当于过去几年的DNS循环。今天你有像任播这样的东西，让你玩各种技巧。您可以非常肯定ebay和amazon之类的东西确实使用了负载均衡器并且他们使用了很多它们。

当你考虑它是如何工作的时候，你可能想要把它煮一点，因为很多流量都是无状态的。在对页面的单个请求中，可能存在许多不需要了解状态的对象。通过从无状态系统（这是任播进入的地方）提供这些对象，将这些对象从图片中取出，并且请求数量急剧下降。

如果这没有达到单个负载均衡器可以处理负载的程度，那么下一步就是使用IP路由和/或地理DNS来中断事务。像ebay和amazon这样大的网站将在许多不同的数据中心，每个数据中心都有大量的互联网连接。你把从互联网流行任务西进来的所有东西都送到西海岸的数据中心“quest”。服务器，来自att-west的任何东西都被发送到西海岸的数据中心“att”。服务器，来自任务东方的任何东西，它进入东海岸数据中心“任务”。这些系统中的每一个都可以是孤岛，可以处理负载的单个负载平衡器，一些负载平衡器可以在一秒钟内处理数十万个甚至SSL加密的事务。在背面，您不断地批量复制到每个数据中心，但它可能不同步。

Answer 4

我不知道他们是如何做到的，但这里有一些建议：

• 为了避免负载均衡器主机本身过载，请使用循环 DNS 或
• 根据负载、设置、地理位置等将不同的客户端重定向到不同的集群地址

为了分配中间层负载，

• 将中间层会话服务器的 ID 嵌入会话 ID cookie 中 - 正如其他人所建议的那样。这样，您点击哪个前端框就无关紧要了，它们可以添加/删除而不会产生任何影响。
• 如果它足够重要，请建立一种在会话期间将客户端重定向到备用中间层服务器的机制，以便可以将其删除以进行维护等。
• 客户端在开始新会话时开始使用新委托的中间层服务器

分配后端数据库负载

• 每个帐户或每个用户数据的“实时”分片
• 异步复制缓慢变化或相对静态的数据；用户可能会发现它已经过时（但大多数情况下不会过时）。中间层和 Web 服务器连接到其所在位置的本地数据库