标签:
我们的产品中有两个Module,分别部署在独立的Linux机器上,Module 1需要向Module 2发起Http请求来获得服务。由于Module 2有多台,因此我们会在Module 2前部署一台负载均衡器(ELB,Elastic Load Balancer)。我们部署在AWS里,因此使用的是AWS ELB。
AWS ELB同时提供另一个很好的功能,叫做Sticky Session,它的作用是帮你把请求定向到其中一台机器,而非随机按ELB算法分散到其他机器。这样功能的好处是,如果我后一个请求依赖前一个请求的处理,那么在这一时间段内,这一系列的请求都会被送到同一台机器处理。
AWS ELB实现这个功能,需要依赖Cookie,在配置时,需要你提供一个Cookie的名字。按道理来讲,ELB会根据请求中此Cookie的值,将相同值的请求送到同一台机器。
但是我们测试,发现,情况并不是这样。Sticky Session没有起作用。
经过排查,最终我们发现,根本原因是:当我们的Http请求送到Module2,得到Response返回时,我们的程序会在Response Header中加入一个cookie,通过SetCookie,这个cookie是我们在ELB配置的用于Sticky Session的Cookie。但是同时ELB还会再我们的Response Header中加入另外一个cookie,名字叫AWSELB,这个cookie我们没有处理。
但其实在下次请求时,我们的Module 1除了要带有自己的cookie,还应该带有AWS ELB的cookie,这样ELB的stricky session功能才起作用。请求才会被定向到某一台特定的Module 2机器。
为什么我们之前没有发现呢?
1. 首先我们没有在Response Header中SetCookie,因此ELB也不会帮我们再Set AWSELB Cookie。
2. ELB更多用于Browser和Server的通信负载均衡。
AWSELB的cookie,path=/,也就是所有后续请求都应该带这个cookie。Browser自然懂得其中道理,能够正确处理。但是对于我们的使用场景,两个Module,用的是网络库,进行http通信,不存在browser这样的client来处理cookie。所以就需要我们自己处理了。
由此也能看出,AWS ELB的使用场景,更多是为浏览器和Server间通信准备。
终于找到了这个问题的原因,希望对你有帮助。
还是应该多思考。
参考文档:
1. http://docs.amazonaws.cn/en_us/ElasticLoadBalancing/latest/DeveloperGuide/US_StickySessions.html
2. http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html#enable-sticky-sessions-application
Kevin Song
2015年6月18日
AWS ELB Sticky Session有问题?别忘了AWSELB cookie
标签:
原文地址:http://www.cnblogs.com/KevinSong/p/4585193.html