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日