Redission-tomcat quickly implements deployment from single machine to multi-machine deployment

Preface

In the early stages of some projects, development and deployment are done on a single machine for the sake of simplicity and speed. However, as the business expands or the requirements for availability increase, the single-machine environment no longer meets the needs. When switching from a single-machine deployment to a multi-machine deployment, an important step may be session sharing (which can be ignored if token-based authentication is used from the beginning). This article introduces a redis-based tomcat session management open source project: redission-tomcat, which can quickly implement session sharing without code intrusion.

Introduction

Redisson is a redis client similar to Jedis, but with richer functions than Jedis. redission-tomcat is a tomcat session manager project based on redis, project address. Compared to other implementations, this project's storage is more efficient and write operations are more optimized. Each session parameter is written to redis when calling HttpSession.setAttribute, while other solutions generally serialize the entire session and write it each time.

use

1. Download the two jar packages redisson-all-3.11.0.jar and redisson-tomcat-8-3.11.0.jar (for tomcat8, other versions can be found in the above project address page) and put them in the lib directory of tomcat.

2. Add the following configuration to the context.xml file in the tomcat conf directory

<Manager className="org.redisson.tomcat.RedissonSessionManager"
configPath="${catalina.base}/conf/redisson.conf" 
readMode="MEMORY" updateMode="AFTER_REQUEST" broadcastSessionEvents="false"/>

in

• configPath: points to the Redisson configuration file in json or yaml format, given in step 3.
• readMode: The reading mode of the session attribute. The possible values ​​are 1. MEMORY, which saves session attributes to both the local Tomcat session and Redis. Subsequent session updates are propagated to the local Tomcat session through Redis events. 2. REDIS, which only saves session attributes to Redis. The default is REDIS.
• updateMode: The update mode of the session attribute. The possible values ​​are: 1. DEFAULT, session attributes are only saved to redis through the setAttribute method; 2. AFTER_REQUEST, after each request, all session attributes are saved to redis. The default is DEFAULT.
• broadcastSessionEvents: If set to true, the sessionCreated and sessionDestroyed events will be broadcast to all tomcat instances and all registered HttpSessionListeners will be triggered. The default value is false.

3. Add a new configuration file redisson.conf in the tomcat conf directory, the content is as follows

{
"singleServerConfig":{
"idleConnectionTimeout":10000,
"connectTimeout":10000,
"timeout":3000,
"retryAttempts":3,
"retryInterval":1500,
"password":"123456",
"subscriptionsPerConnection":5,
"clientName":null,
"address": "redis://127.0.0.1:6379",
"subscriptionConnectionMinimumIdleSize":1,
"subscriptionConnectionPoolSize":50,
"connectionMinimumIdleSize":24,
"connectionPoolSize":64,
"database":0,
"dnsMonitoringInterval":5000
},
"threads":16,
"nettyThreads":32,
"codec":{
"class":"org.redisson.codec.FstCodec"
},
"transportMode":"NIO"
}

The above is the redis environment configuration for stand-alone mode, where password and address are modified to your own values. If it is cluster mode, the configuration file is

{
"sentinelServersConfig":{
"idleConnectionTimeout":10000,
"connectTimeout":10000,
"timeout":3000,
"retryAttempts":3,
"retryInterval":1500,
"failedSlaveReconnectionInterval":3000,
"failedSlaveCheckInterval":60000,
"password":null,
"subscriptionsPerConnection":5,
"clientName":null,
"loadBalancer":{
"class":"org.redisson.connection.balancer.RoundRobinLoadBalancer"
},
"subscriptionConnectionMinimumIdleSize":1,
"subscriptionConnectionPoolSize":50,
"slaveConnectionMinimumIdleSize":24,
"slaveConnectionPoolSize":64,
"masterConnectionMinimumIdleSize":24,
"masterConnectionPoolSize":64,
"readMode":"SLAVE",
"subscriptionMode":"SLAVE",
"sentinelAddresses":[
"redis://127.0.0.1:26379",
"redis://127.0.0.1:26389"
],
"masterName":"mymaster",
"database":0
},
"threads":16,
"nettyThreads":32,
"codec":{
"class":"org.redisson.codec.FstCodec"
},
"transportMode":"NIO"
}

We can use nginx to achieve load balancing, refer to the configuration

upstream cnserver{
server 127.0.0.1:8080 weight=2 fail_timeout=10s max_fails=1;
server 127.0.0.1:8081 weight=2 fail_timeout=10s max_fails=1;
}
server {
listen 80;
server_name localhost;
index index.html index.htm;
location /rest/ {
index index.html;
proxy_pass http://cnserver/rest/;
}
}

The above is all the configurations for using redisson-tomcat to implement single-machine deployment to multi-machine deployment.

Summarize

The technical architecture continues to evolve as the business develops. In the early stages of business development, the number of users and business complexity are relatively low. In order to achieve rapid online verification, a simple and single architecture is often adopted. Many projects may fail before they have time to evolve and upgrade their architecture, but those projects that are fortunate enough to continue to grow will inevitably be continuously optimized and upgraded as their business expands.

The redisson-tomcat introduced in this article can help single-machine projects quickly switch to multi-machine support, of course only in the session management link. If other distributed supports such as file upload, scheduled tasks, etc. are involved, corresponding adjustments must be made.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.