无法完全无状态的大型网站如何在Web层实现极高的可扩展性？
像eBay和亚马逊这样的网站，不能完全无国籍，因为他们有购物车或类似的东西。将购物车中的每个项目编码到URL中是不可行的，也不可能将每个项目编码到cookie中并在每个连接处发送它。所以亚马逊只是将session-id存储到正在发送的cookie中。所以我理解eBay和亚马逊的Web层的可扩展性应该比谷歌搜索引擎的可扩展性要困难得多，谷歌搜索引擎可以将所有内容编码到URL中。
另一方面，eBay和亚马逊的规模都非常大。有传言说eBay上有大约15000个J2EE应用服务器。
这些网站如何处理这两者：极端可扩展性和有状态？由于站点是有状态的，因此进行简单的DNS平衡是不可行的。因此可以假设这些公司有一个基于硬件的负载均衡器，如BigIP，Netscaler或类似的东西，这是该站点的单个IP地址背后的唯一设备。此负载均衡器将解密SSL（如果已编码），检查cookie并根据该cookie的会话ID决定哪个应用程序服务器持有该客户的会话。
但是这不可能有效，因为没有一个负载均衡器可以处理数千个应用服务器的负载？我想，即使这些硬件负载平衡器也不能扩展到这样的水平。
此外，负载平衡正在为用户透明地完成，即用户不会转发到不同的地址，但仍然全部集中在www.amazon.com上。
所以我的问题是：是否有一些特殊的技巧可以实现像Web层的透明分片（通常不是数据库层）？只要未检查cookie，就无法知道哪个应用程序服务器正在举行此会话。
编辑：我意识到只需要透明度，如果需要对网站进行拼接和添加书签。例如。如果该网站仅仅是一个网络应用程序，比如飞机或火车票预订系统，那么将用户重定向到不同网址后面的特定网络服务器集群应该没有问题，例如a17.ticketreservation.com。在这种特定情况下，仅使用多个应用服务器集群是可行的，每个应用服务器集群都在他自己的负载均衡器之后。 有趣的是，我没有找到使用这种概念的网站。 修改：我在discussed找到了这个概念highscalability.com，其中讨论的内容是雷朱的一篇名为 "Client Side Load Balancing for Web 2.0 Applications" 的文章。雷朱使用交叉脚本透明地进行客户端负载均衡。
即使存在书签，xss等缺点，我也认为对于某些特殊情况，这几乎是一个非常好的主意，即几乎无内容的Web应用程序，不需要被蜘蛛网或书签（例如票务预订系统或类似的东西）。然后就没有必要透明地进行负载均衡。
可能存在从主站点到服务器的简单重定向，例如从www.ticketreservation.com重定向到a17.ticketreservation.com。从那里，用户停留在服务器a17。 a17不是服务器，而是集群本身，可以实现冗余。
初始重定向服务器本身可以是负载均衡器后面的集群。这样，可以实现真正高的可扩展性，因为www后面的主要负载均衡器仅在每个会话开始时被击中一次。
当然，重定向到不同的网址看起来非常讨厌，但仅仅是网络应用程序（无论如何都不需要蜘蛛网，深层链接或深度书签），这应该只是用户的光学问题？
重定向集群可以轮询应用集群的负载并相应地调整重定向，从而实现平衡而不仅仅是负载分配。
答案 0 :(得分：2)
您可能必须在其中一个地方的工程团队中确认无疑，但是有些人从两个地方的谈话和其他信息中做出了有根据的猜测：
Ebay Architecture和Amazon Architecture
在当今世界中，只有一个负载均衡器本身就相当于过去几年的DNS循环。今天你有anycast之类的东西可以让你玩各种各样的技巧。您可以非常肯定ebay和amazon之类的东西确实使用了负载均衡器并且他们使用了很多它们。
当你考虑它是如何工作的时候，你可能想要把它煮一点，因为很多流量都是无状态的。在对页面的单个请求中，可能存在许多不需要了解状态的对象。通过从无状态系统（这是任播进入的地方）提供这些对象，将这些对象从图片中取出，并且请求数量急剧下降。
如果这没有达到单个负载均衡器可以处理负载的程度，那么下一步就是使用IP路由和/或地理DNS来中断事务。像ebay和amazon这样大的网站将在许多不同的数据中心，每个数据中心都有大量的互联网连接。你把所有从互联网流行任务西进来的东西送到西海岸的数据中心“任务”服务器，任何来自att-west的东西都被发送到西海岸数据中心的“att”服务器，任何东西来自quest-east，它去了东海岸数据中心“任务”服务器等。这些系统中的每一个都可以是岛屿，可以处理负载的单个负载平衡器，一些负载平衡器可以处理数十万个事务，甚至SSL加密。在背面，您不断地批量复制到每个数据中心，但它可能不同步。
答案 1 :(得分：2)
您可能会发现以下文章非常有用，该文章介绍了亚马逊某些核心服务用于提供“永远在线”体验的高可用键值存储系统的设计和实现：
Giuseppe DeCandia，Deniz Hastorun，Madan Jampani，Gunavardhan Kakulapati，Avinash Lakshman，Alex Pilchin，Swami Sivasubramanian，Peter Vosshall和Werner Vogels ，“ Dynamo: Amazon's Highly Available Key-Value Store “，在第21届ACM操作系统原理研讨会论文集，华盛顿史蒂文森，2007年10月。
答案 2 :(得分：2)
我不知道他们是怎么做的，但这里有一些建议：
分发中间层负载，
分发后端数据库负载
答案 3 :(得分：1)
易。无状态的Web服务器是负载平衡的。保存会话数据的应用程序服务器（中间层）不是。 Web服务器可以使用您的会话ID cookie来确定要联系的应用服务器。
Memcached和微软的Velocity是解决这一需求的产品。
编辑：网络服务器如何知道要联系哪个应用服务器？这嵌入到会话ID哈希中，一般情况下可以随意完成。它可以像你的会话ID一样简单就是服务器：guid。不过，Memcached基于哈希值。
重要的是，客户必须能够找出以无状态方式联系的应用服务器。最简单的方法是将其嵌入到密钥中，尽管注册表（可能在它自己的层上）也能正常工作并且可以提供一些容错功能。
Edit2：回到some Ebay interviews，我可能已经了解了他们的实施细节有点不对劲。他们不做缓存，他们不在中间层做状态。他们所做的是拥有按功能划分的负载平衡中间层（app服务器）。因此，他们将拥有一个服务器池，例如，查看项目。然后是另一个用于销售物品的游泳池。
这些应用服务器有一个“智能”DAL，可以路由到分片数据库（按功能和数据分区，因此Database1上的用户AL，Database2上的用户MZ，Items1上的项目1-10000等）。
他们在中间层没有状态，因为它们是按功能划分的。因此，正常的用户体验将涉及超过1个应用服务器池。假设您查看某个项目（ViewAppServerPool），然后对项目（BidAppServerPool）进行投标。所有这些应用服务器都必须保持同步，然后需要分布式缓存来管理所有内容。但是，它们的规模如此之大，以至于没有分布式缓存可以有效地管理它，单个数据库服务器也不能。这意味着他们必须对数据层进行分片，并且任何缓存实现都必须在相同的边界上进行分割。
这与我上面发布的类似，只是向下移动了一层。应用服务器不是让Web服务器确定要联系哪个应用服务器，而是确定要联系哪个数据库。只有在Ebay的情况下，由于它们的分区策略，它实际上可能会击中20多个数据库服务器。但是，同样，无状态层具有某种用于联系有状态层的规则。然而，Ebay的规则比我上面解释的简单化的“User1 on Server10”规则要复杂一些。