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