Introduction to session processing methods in Linux cluster/distributed environment

This article mainly introduces you to the five strategies for session processing in Linux cluster/distributed environment. The article introduces it in great detail through sample codes and pictures. It has certain reference learning value for everyone's study or work. Friends who need it, please follow the editor to learn together.

Preface

Generally, after we build a cluster environment, one issue we have to consider is how to handle sessions generated by user access. If no processing is done, users will log in frequently. For example, there are two servers A and B in the cluster. When the user visits the website for the first time, Nginx will forward the user request to server A through its load balancing mechanism. This will At this time, server A will create a Session for the user. When the user sends a request for the second time, Nginx will load balance the request to server B. At this time, server B does not have a Session, so the user will be kicked to the login page. This will greatly reduce the user experience and lead to the loss of users. This situation should never occur in the project.

We should process the generated Session to ensure user experience through sticky Session, Session copying or Session sharing.

Below I will explain 5 Session processing strategies and analyze their advantages and disadvantages. Not much to say, let’s take a look at the detailed introduction.

First type: sticky session

Principle: Sticky Session refers to locking the user to a certain server , such as the example mentioned above, when the user requests for the first time, the load balancer forwards the user's request to server A. If the load balancer sets a sticky session, then every subsequent request of the user will be forwarded to server A. , which is equivalent to sticking the user and server A together. This is the sticky Session mechanism.

Advantages: Simple, no need to do any processing on the session.

Disadvantages: Lack of fault tolerance. If the currently accessed server fails and the user is transferred to the second server, his session information will be invalid.

Applicable scenarios: Failure has a small impact on customers; server failure is a low-probability event.

Implementation method: Take Nginx as an example. Sticky Session can be achieved by configuring the ip_hash attribute in the upstream module.

upstream mycluster{
 #这里添加的是上面启动好的两台Tomcat服务器
 ip_hash;#粘性Session
  server 192.168.22.229:8080 weight=1;
  server 192.168.22.230:8080 weight=1;
}

Second type: server session replication

Principle: Any When the session on a server changes (addition, deletion, modification), the node will serialize all the contents of the session and then broadcast it to all other nodes, regardless of whether other servers need the session, to ensure session synchronization.

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

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

Implementation method:

① Set tomcat, server.xml turns on tomcat cluster function

Address: fill in Just use the local IP address and set the port number to prevent port conflicts.

② Add information to the application: notify that the application is currently in a cluster environment and supports distributed

Add options in web.xml<distributable/>

The third type: session sharing mechanism

Use distributed caching solutions such as memcached and redis, but Memcached or Redis must be cluster.

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

① Sticky session processing method

Principle: Different tomcat designated access Different master memcached. Information between multiple Memcached is synchronized, enabling master-slave backup and high availability. When a user accesses, he first creates a session in tomcat, and then copies the session to its corresponding memcahed. Memcache only plays a backup role, and all reading and writing are done on tomcat. When a certain tomcat hangs up, the cluster locates the user's access to the backup tomcat, and then searches for the session based on the SessionId stored in the cookie. If it cannot find the session, it goes to the corresponding memcached to retrieve the session. After finding it, it copies it to the backup tomcat. superior.

② Non-sticky session processing method

Principle: memcached does master-slave replication, and writes to sessions are written to the slave memcached service , reads are all read from the main memcached, tomcat itself does not store the session

Advantages:Fault-tolerant, session responds in real time.

Implementation method: Use the open source msm plug-in to solve the session sharing between tomcats: Memcached_Session_Manager (MSM)

a. 复制相关jar包到tomcat/lib 目录下

JAVA memcached客户端：spymemcached.jarmsm项目相关的jar包：1. 核心包，memcached-session-manager-{version}.jar2. Tomcat版本对应的jar包：memcached-session-manager-tc{tomcat-version}-{version}.jar序列化工具包：可选kryo，javolution,xstream等，不设置时使用jdk默认序列化。

b. 配置Context.xml ，加入处理Session的Manager

粘性模式配置：

非粘性配置：

 

第四种：session持久化到数据库

原理：就不用多说了吧，拿出一个数据库，专门用来存储session信息。保证session的持久化。

优点：服务器出现问题，session不会丢失

缺点：如果网站的访问量很大，把session存储到数据库中，会对数据库造成很大压力，还需要增加额外的开销维护数据库。

第五种terracotta实现session复制

原理：Terracotta的基本原理是对于集群间共享的数据，当在一个节点发生变化的时候，Terracotta只把变化的部分发送给Terracotta服务器，然后由服务器把它转发给真正需要这个数据的节点。可以看成是对第二种方案的优化。

优点：这样对网络的压力就非常小，各个节点也不必浪费CPU时间和内存进行大量的序列化操作。把这种集群间数据共享的机制应用在session同步上，既避免了对数据库的依赖，又能达到负载均衡和灾难恢复的效果。

实现方式：篇幅原因，下篇再论。

小结

以上讲述的就是集群或分布式环境下，session的5种处理策略。其中就应用广泛性而言，第三种方式，也就是基于第三方缓存框架共享session，应用的最为广泛，无论是效率还是扩展性都很好。而Terracotta作为一个JVM级的开源群集框架，不仅提供HTTP Session复制，它还能做分布式缓存，POJO群集，跨越群集的JVM来实现分布式应用程序协调等，也值得学习一下。

The above is the detailed content of Introduction to session processing methods in Linux cluster/distributed environment. For more information, please follow other related articles on the PHP Chinese website!