有像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.在这种特定情况下,仅使用多个应用服务器集群是可行的,每个集群都在他自己的负载均衡器之后.
有趣的是,我没有找到使用这种概念的网站.
编辑：我在highscalability.com发现了这个概念discussed,其中讨论是指雷朱的一篇名为“Client Side Load Balancing for Web 2.0 Applications”的文章.雷朱使用交叉脚本来透明地进行客户端负载均衡.
即使存在书签,xss等缺点,我也认为对于某些特殊情况,这几乎是一个非常好的主意,即几乎无内容的Web应用程序,不需要被蜘蛛网或书签(例如机票预订)系统或类似的东西).然后就不需要透明地进行负载均衡.
可以存在从主站点到服务器的简单重定向,例如,从www.ticketreservation.com重定向到a17.ticketreservation.com.从那里,用户停留在服务器a17. a17不是服务器,而是集群本身,通过它可以实现冗余.
初始重定向服务器本身可以是负载均衡器后面的集群.这样,可以实现非常高的可伸缩性,因为www后面的主要负载均衡器仅在每个会话开始时被击中一次.
当然,重定向到不同的网址看起来非常讨厌,但仅仅是网络应用程序(无论如何不需要蜘蛛网,深层链接或深度书签),这应该只是用户的光学问题？
重定向集群可以轮询应用程序集群的负载并相应地调整重定向,从而实现平衡而不仅仅是负载分配.
解决方法
Memcached和微软的Velocity是解决这一确切需求的产品.
编辑：Web服务器如何知道要联系哪个应用服务器？这嵌入到会话ID哈希中,一般情况下你可以这样做.它可能就像你的会话ID是server：guid一样简单.不过,Memcached基于哈希.
重要的是客户必须能够找出以无状态方式联系的应用服务器.最简单的方法是将其嵌入到密钥中,尽管注册表(可能在它自己的层上)也可以工作,并且可以提供一些容错功能.
编辑2：回到some Ebay interviews,我可能已经得到了他们的实施细节有点不对劲.他们不做缓存,他们不在中间层做状态.他们所做的是拥有一个按功能划分的负载平衡中间层(app服务器).因此,他们将拥有一个服务器池,查看项目.然后是另一个销售物品的池子.
这些应用程序服务器具有“智能”DAL,可以路由到分片数据库(按功能和数据分区,因此Database1上的用户A-L,Database2上的用户M-Z,Items1上的项目1-10000等).
它们在中间层没有状态,因为它们按功能划分.因此,正常的用户体验将涉及超过1个应用服务器池.假设您查看某个项目(ViewAppServerPool),然后对某个项目(BidAppServerPool)进行投标.所有这些应用服务器都必须保持同步,然后需要分布式缓存来管理所有内容.但是,它们的规模如此之大,以至于没有分布式缓存可以有效地管理它,单个数据库服务器也不能.这意味着他们必须对数据层进行分片,并且任何缓存实现都必须在相同的边界上进行分割.
这与我上面发布的内容类似,只是向下移动了一层.应用服务器不是让Web服务器确定要联系哪个应用服务器,而是确定要联系的数据库.只有在Ebay的情况下,由于它们的分区策略,它实际上可能会击中20个数据库服务器.但是,同样,无状态层具有某种用于联系有状态层的规则.然而,Ebay的规则比我上面解释的简单化的“User1 on Server10”规则要复杂一些.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。