The session consistency

The first type: sticky session

Principle: A sticky Session is when the user is locked to A certain server. For example, the load balancer forwards the user’s first request to server A. If the load balancer sets A sticky Session, the user’s every subsequent request will be forwarded to server A. If the load balancer sets A sticky Session, the user’s every request will be forwarded to server A. You’re basically sticking the user and server A together, and that’s the sticky Session mechanism.

Advantages: Simple, no need to do anything with the session.

Disadvantages: Lack of fault tolerance, if the currently accessed server fails, the user’s session information will be invalid if he is moved to a second server.

Application scenario: A fault has little impact on customers. A server failure is a low-probability event.

Implementation: Take Nginx as an example, you can configure the IP_hash attribute in the upstream module to implement a sticky Session.

Upstream mycluster{# add ip_hash to Tomcat server ip_hash; # Sticky Session server 192.168.22.29:8080 weight=1; Server 192.168.22.230:8080 weight = 1; }Copy the code

The second is server session replication

How it works: When a session changes on any server, the node serializes the contents of that session and broadcasts them to all other nodes, whether or not the other servers need the session, to ensure that the session is synchronized.

Advantages: Fault-tolerant, sessions between servers can respond in real time.

Disadvantages: It will cause a certain pressure on the network load. If the number of sessions is large, it may cause network congestion and slow down the server performance.

Implementation method:

① Set tomcat, server. XML to enable the Tomcat cluster function

Address: Enter the local IP Address and set the port number to prevent port conflicts.

(2) Add information to the application: Notifying the application that it is currently in a cluster environment, enabling distributed options to be added to web.xml

Third: Session sharing mechanism

Use distributed caching schemes such as memcached and Redis, but require that memcached or Redis be clustered.

There are two mechanisms for using Session sharing. The two mechanisms are as follows:

① Processing mode of sticky session

How it works: Different Tomcat specifications access different primary memcached. Information is synchronized across multiple Memcached devices, enabling primary/secondary backup and high availability. The user first creates a session in Tomcat and then copies the session to its corresponding memcahed. Memcache is used for backup only. Both reads and writes are on Tomcat. When a Tomcat fails, the cluster locates the user access to the standby Tomcat, and then searches for the session based on the session ID stored in the cookie. If the session cannot be found, the cluster accesses the corresponding memcached session, and then copies the session to the standby Tomcat.

(2) Processing mode of non-sticky session

Principles: Memcached is a master slave replication. All writes to the slave memcached service and all reads are read from the master memcached service. Tomcat itself does not store sessions

Advantages: Fault tolerant, real-time session response.

Memcached_Session_Manager (MSM)

A. Copy related JAR packages to the tomcat/lib directory

JAVA memcached client: Spymemcached. Jar Memcached -session-manager-{version}.jar Memcached -session-manager-tc{tomcat-version}-{version}. Jar Serialization package: Optional kryo, javolution,xstream, etc. If not set, use JDK default serialization. B. Configure context. XML and add it to the Session ManagerCopy the code

Stickiness mode configuration:

inviscid

Fourth: Session persistence toThe database

How it works: Needless to say, take out a database that stores session information. Ensure session persistence.

Advantages: If the server is faulty, the session is not lost

Cons: If the site is heavily visited, storing the session in the database can put a lot of pressure on the database and add additional overhead to maintain the database.

The fifth terracotta implements session replication

How it works: The basic principle of Terracotta is that when a node changes, Terracotta only sends the changed part to the Terracotta server, which then forwards it to the node that really needs the data. You can view it as an optimization of the second option.

Advantages: This puts very little pressure on the network, and the individual nodes don’t have to waste CPU time and memory doing a lot of serialization. This mechanism of data sharing among clusters is applied to session synchronization, which not only avoids the dependence on database, but also achieves the effect of load balancing and disaster recovery.

summary

These are the five strategies for handling sessions in a clustered or distributed environment. Among them, in terms of wide application, the third way, namely sharing session based on the third-party cache framework, is the most widely used and has good efficiency and scalability. Terracotta is an open source cluster framework at the JVM level that provides not only HTTP Session replication, but also distributed caching, POJO clustering, and distributed application coordination across clustered JVMS.

A single point of access

  • Single sign-on: once a place is logged in, all places associated with it can be logged in

  • The main problem is twofold:

    • Single sign-on is also a login, HTTP stateless, and must also be addressed with sessions and cookies
    • Session sharing: The above solutions,
    • Cookie cross-domain
      • Multiple domains share cookies and set the domain of the Cookie when written to the client.
      • The Cookie is parsed on the client side and added to the requested URL

reference

Here the reference place forgot, own notes above no record