粘性和非粘性会话 [英] Sticky and NON-Sticky sessions
问题描述
我想知道粘性会话和非粘性会话之间的区别.从互联网上阅读后我了解的内容:
粘性:只有单个会话对象.
非粘性会话:每个服务器节点的会话对象
当您的网站仅由一个Web服务器提供服务时，对于每个客户端/服务器对，都会创建一个会话对象并将其保留在Web服务器的内存中.来自客户端的所有请求都将转到此Web服务器并更新此会话对象.如果在交互期间需要将某些数据存储在会话对象中，则将数据存储在此会话对象中，并在存在会话的任何时间都保持在那里.
但是，如果您的网站由位于负载均衡器后面的多个Web服务器提供服务，则负载均衡器将决定每个请求应访问的实际(物理)Web服务器.例如，如果负载均衡器后面有3个Web服务器A，B和C，则可能从服务器A服务www.mywebsite.com/index.jsp，而从服务器A服务www.mywebsite.com/login.jsp服务器B提供服务器B和www.mywebsite.com/accoutdetails.php.
现在，如果(物理上)从3个不同的服务器处理请求，则每个服务器都为您创建了一个会话对象，并且由于这些会话对象位于三个独立的盒子上，因此无法直接知道其中的内容另一个的会话对象.为了在这些服务器会话之间进行同步，您可能必须将会话数据写入/读取到所有人都通用的层中(例如DB).现在，对于这种用例，将数据写入数据库或从数据库读取数据可能不是一个好主意.现在，出现粘性会话的角色.
如果指示负载平衡器使用粘性会话，则即使存在其他服务器，所有交互都将在同一物理服务器上进行.因此，在与该网站的整个交互过程中，您的会话对象将是相同的.
总而言之，在粘性会话"的情况下，您的所有请求都将定向到同一台物理Web服务器，而在非粘性负载平衡器的情况下，可以选择任何Web服务器来满足您的请求.
作为示例，您可以在此处阅读有关Amazon的Elastic Load Balancer和粘性会话的信息: 解决方案
When your website is served by only one web server, for each client-server pair, a session object is created and remains in the memory of the web server. All the requests from the client go to this web server and update this session object. If some data needs to be stored in the session object over the period of interaction, it is stored in this session object and stays there as long as the session exists.
However, if your website is served by multiple web servers which sit behind a load balancer, the load balancer decides which actual (physical) web-server should each request go to. For example, if there are 3 web servers A, B and C behind the load balancer, it is possible that www.mywebsite.com/index.jsp is served from server A, www.mywebsite.com/login.jsp is served from server B and www.mywebsite.com/accoutdetails.php are served from server C.
Now, if the requests are being served from (physically) 3 different servers, each server has created a session object for you and because these session objects sit on three independent boxes, there's no direct way of one knowing what is there in the session object of the other. In order to synchronize between these server sessions, you may have to write/read the session data into a layer which is common to all - like a DB. Now writing and reading data to/from a db for this use-case may not be a good idea. Now, here comes the role of sticky-session.
If the load balancer is instructed to use sticky sessions, all of your interactions will happen with the same physical server, even though other servers are present. Thus, your session object will be the same throughout your entire interaction with this website.
To summarize, In case of Sticky Sessions, all your requests will be directed to the same physical web server while in case of a non-sticky loadbalancer may choose any webserver to serve your requests.
As an example, you may read about Amazon's Elastic Load Balancer and sticky sessions here : http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html
这篇关于粘性和非粘性会话的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
