Difference between session affinity and sticky session?

Question

What is the difference between session affinity and sticky session in context of load balancing servers?

Solution 1

I've seen those terms used interchangeably, but there are different ways of implementing it:

1. Send a cookie on the first response and then look for it on subsequent ones. The cookie says which real server to send to.
   Bad if you have to support cookie-less browsers
2. Partition based on the requester's IP address.
   Bad if it isn't static or if many come in through the same proxy.
3. If you authenticate users, partition based on user name (it has to be an HTTP supported authentication mode to do this).
4. Don't require state.
   Let clients hit any server (send state to the client and have them send it back)
   This is not a sticky session, it's a way to avoid having to do it.

I would suspect that sticky might refer to the cookie way, and that affinity might refer to #2 and #3 in some contexts, but that's not how I have seen it used (or use it myself)

Solution 2

As I've always heard the terms used in a load-balancing scenario, they are interchangeable. Both mean that once a session is started, the same server serves all requests for that session.

Solution 3

Sticky session means that when a request comes into a site from a client all further requests go to the same server initial client request accessed. I believe that session affinity is a synonym for sticky session.

Solution 4

They are the same.

Both mean that when coming in to the load balancer, the request will be directed to the server that served the first request (and has the session).

Solution 5

Sticky session means to route the requests of particular session to the same physical machine who served the first request for that session.

View more solutions

Comments

[Martin McNulty]

Seemingly no longer available, but there's a copy in the Wayback machine

[Ruan Mendes]

This is why you don't just post links without an explanation

[raffian]

If a request is bound to a physical server, what happens if that server fails? Is there a strategy to use the cookie to contain a fail-over server?

[SirDarius]

If the server fails, the application fails -- maybe you need to login again. Maybe you have lost data. Usually, the load-balancer picks another server and you keep going, but some state is lost. If this is unacceptable, then you need to get the state to the DB or other servers as quick as possible or have a stateless strategy.

[RandallB]

FWIW Heroku refers to them as the opposite. Session Afifinity is cookie based, and it doesn't support sticky. devcenter.heroku.com/articles/session-affinity

[aveek]

Found that the content of the above link (no longer available now) has been moved to archive.li/SG4fA It basically lists down the various persistence types supported by the F5 load balancer.