AWS ELB Sticky Session有问题？别忘了AWSELB cookie

　　咱们的产品中有两个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日