Four session processing strategies in cluster/distributed environment

Reference materials: 1. 5 session processing strategies in a cluster/distributed environment

One, sticky session

Configure ip_hash in the upstream in nginx; make the client bind the server that is accessed for the first time.

Two, server session replication

Configure the cluster version for Tomcat and enable the network broadcast strategy. After a node receives the session, all other nodes synchronize the session of the node.

2.1, terracotta realizes session replication (optimized version)

Corracotta sends the changed data of a node, and then terracotta sends the changed data to the terracotta server, and finally to the node that needs the data.

Third, the database persistence operation

Disadvantages: When the amount of visits is large, it will cause great access pressure to the database

Fourth, session sharing mechanism (two ways)

Borrowing distributed cache memcached, redis, must be a cluster

4.1, sticky session

Each Tomcat corresponds to a memcached, data synchronization between memcached. First create a session on a node, and then synchronize to the corresponding memcached. When a node hangs up, get the session from another node, if not, get it from the corresponding memcached.

4.2, non-sticky session

Memcached establishes master-slave replication, writing from memcached and reading from memcached. Tomcat itself does not store session information.

Guess you like

Origin blog.csdn.net/weixin_43983411/article/details/108970123