Nginx+tomcat+redis load balancing to achieve session sharing

Experimental environment description:

系统： centos 7.4  3.10.0-327.el7.x86_64
docker： 18.03.0-ce
docker-compose：docker-compose version 1.21.0
redis： 4.0.9
nginx： 1.12.2
tomcat：8.5.30
jdk：1.8.161

1. Brief description

Session unified solution:
1. The session retention mechanism of a single machine is like nginx's ip-hash. If a single machine goes offline, all sessions will be lost
. 2. Session sharing, such as a tomcat cluster, multiple application servers share a synchronous session, a single machine When the machine is offline, according to the load balancing principle, the scheduler will traverse to find available nodes. The disadvantage is that it can only be the same middleware such as a tomcat cluster. In addition, session replication will bring performance loss. Session content is synchronized to members through broadcast, which will cause network traffic bottlenecks.
3. The session server such as memcached/redis, the application server will save the session in the cache db after accepting the request. When there is a problem with the application server, the scheduler will traverse all nodes. If it is found, it will be copied to the local machine, so that session sharing and high availability can be achieved.
Experiment with using the session server

tomcat:
Tomcat has three working modes: independent servlet, in-process servlet, and out-of-process servlet.
Tomcat is a component-based server, and its building components are configurable. The outermost component is the Catalina Servlet container, and other groups must be configured in this top-level container according to certain format requirements.
　　Tomcat components are configured in the $CATLINA_HOME/conf/server.xml file.
tomat is a servlet container that handles http requests. In normal use, we will enter the http address in the browser to access service resources, such as the format http://host[":"port][abs_path], here we use it as middleware .

nginx
nginx load balancing implementation: respectively

• polling,
• weighted round robin,
• least-conn, least connection
• ip-hash,
• fail,
• url-hash

MySQL master-slave theory

• 1. After the master-slave connection is established
• 2. The slave library will generate an IO thread and an SQL thread,
• 3. The IO thread will request the binary log of the main library and record the log to the local relay log
• 4. The main library will generate a log dump thread to pass the binary log to the IO thread of the slave library
• 5. The SQL thread of the slave library will parse the relay log to generate specific operations, and finally achieve consistent data consistency between master and slave operations.
  The theory needs to be further improved, and the experimental topology is as follows

2. Topology

In order to better understand the installation, the software is installed directly from the source code

3. Installation

3.1, docker installation

You need to understand the basic principles first: Docker basics , the fourth section
 is composed of docker installation: docker daemon, docker client, mirror, warehouse, container
client connects to the server through api, and the local command is executed. After the server is executed, it is returned to the client, mirroring It can be downloaded directly from dockerhub, the image can generate a container, the container can be packaged into an image, and the warehouse can save the image. As shown

3.2, nginx installation