I spent a lot of time looking for a way to push the newly developed code into the production system to be able to 0 downtime and 0 impact on the use of the user.
My idea is to use the cluster to do this, by notifying the load Balancer Nginx, remove the Tomcat node in the cluster, and then upgrade the application on Tomcat, and then notify the load Balancer Nginx to reload the Tomcat node. Do this in turn to replace all Tomcat in the cluster once.
So the question is, how do you have no impact on the user when you remove the Tomcat node and load the new tomcat node? The method is simple, sharing session.
Below, we use an example to illustrate this scenario. Our example uses a nginx for load balancing, the back end is hooked up to two Tomcat, and each Tomcat session is saved to the Redis database. The Nginx configuration is non-sticky run mode, which means that each request can be assigned to any node in the cluster. When new code is to be launched, simply remove the Tomcat instance and all access users will be routed to the active Tomcat instance, and the active user will not be affected because the session data is stored in the Redis database. When the tomcat update is complete, you can add this node to the Nginx.
Installing Nginx
# sudo rpm-ivh nginx-1.4.2-1.el6.ngx.x86_64.rpm
Modify the configuration file/etc/nginx/nginx.conf, and add the following:
HTTP {
Upstream Tomcat {
Server localhost:8080;
Server localhost:8081;
}
Include/etc/nginx/mime.types;
Default_type Application/octet-stream;
Modify the configuration file/etc/nginx/conf.d/default.conf and replace the contents of the Location section:
Location/{
Proxy_pass Http://tomcat;
}
Re-start Nginx
# sudo service nginx restart
Next, install the two Tomcat instances. Since we are demonstrating on the same server, to make the two tomcat non-conflicting, you need to modify the port number of the second Tomcat instance. Because Nginx is configured as Non-sticky run mode, the Round-robin load Balancing method is used for each request, which means that it will draw a new session for each request.
Next, download and install Redis. Step omitted, very simple.
Finally, we need to configure Tomcat to have Tomcat save session sessions to the Redis database.
We want to use third-party libraries such as Tomcat-redis-session-manager, home page see:
Https://github.com/jcoleman/tomcat-redis-session-manager
Note that this library is not out-of-the-box and requires some tweaking when used. You need to download the source code and rebuild the project after updating the version of the dependent library. For example, I used Commons-pool2-2.2.jar and Jedis-2.6.1.jar dependent libraries. Remember to copy these jar files to the Lib subdirectory of each Tomcat instance.
After updating the Commons-pool, Jedis, and Tomcat versions of these libraries, you can use Build.gradle to build the entire project. After the build is complete, copy the newly generated Tomcat-redis-session-manager-1.2.jar to the Lib subdirectory of each Tomcat instance. and modify the Context.xml configuration file for each Tomcat instance:
<valve classname= "Com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve"/>
<manager classname= "Com.orangefunction.tomcat.redissessions.RedisSessionManager"
host= "localhost"
Port= "6379"
database= "0"
Maxinactiveinterval= "/>"
Restart the Tomcat instance. You can check that Redis does save the session for Tomcat. Then, when we remove or restore the Tomcat instance, the access user is indeed unaffected.
- This article is from: Linux Learning Network
Use Redis to store the session of the Tomcat cluster