Esquema de sesión distribuida
Que es Session
¿Qué es una sesión? El navegador tiene una cookie. Esta cookie existe por un período de tiempo. Luego, cada vez que se envía una solicitud, traerá una cookie jsessionid especial. En base a esto, se puede mantener un dominio de sesión correspondiente en el lado del servidor, y se pueden colocar en él. 儿 数据。 Datos del niño.
Generalmente, mientras no cierre el navegador y la cookie siga ahí, la sesión correspondiente estará ahí, pero si la cookie se ha ido, la sesión ha desaparecido. Se encuentra comúnmente en carritos de compras y similares, así como en la preservación del estado de inicio de sesión y similares.
Pero está bien reproducir sesiones como esta en un sistema monolítico, pero si eres un sistema distribuido, ¿dónde se mantiene el estado de la sesión para tantos servicios?
De hecho, existen muchos métodos, pero hay dos métodos comunes y de uso común
tomcat + redis
En realidad, esto es bastante conveniente, es decir, el código para usar la sesión es el mismo que antes, o se basa en el soporte de sesión nativo de tomcat, y luego se usa una cosa llamada Tomcat RedisSessionManager, de modo que todos los tomcats que implementemos se almacenarán los datos de la sesión en redis. can.
Configúrelo en el archivo de configuración de tomcat
<Valve className="com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve" />
<Manager className="com.orangefunction.tomcat.redissessions.RedisSessionManager"
host="{redis.host}"
port="{redis.port}"
database="{redis.dbnum}"
maxInactiveInterval="60"/>
Simplemente haga una configuración similar a la anterior, puede ver si usa RedisSessionManager y luego especifique el host y el puerto de redis.
<Valve className="com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve" />
<Manager className="com.orangefunction.tomcat.redissessions.RedisSessionManager"
sentinelMaster="mymaster"
sentinels="<sentinel1-ip>:26379,<sentinel2-ip>:26379,<sentinel3-ip>:26379"
maxInactiveInterval="60"/>
También puede usar el método anterior para guardar datos de sesión basados en el clúster de alta disponibilidad de redis compatible con redis sentinel, todos los cuales están bien
Pero obtenemos los datos de la sesión, de hecho, tomcat obtendrá la sesión de redis.
Pero el problema es que depende en gran medida del contenedor web
Sesión de primavera + redis
La sesión distribuida se vuelve a acoplar en tomcat. Si quiero migrar el contenedor web al embarcadero, ¿configuras todo el embarcadero de nuevo?
Porque el método de tomcat + redis anterior es fácil de usar, pero dependerá en gran medida del contenedor web y no es fácil trasladar el código a otros contenedores web, especialmente si cambia la pila de tecnología. Por ejemplo, se reemplaza por una nube de primavera o una bota de primavera. Tengo que pensarlo.
Entonces, la mejor solución integral se basa en java, spring. People Spring básicamente empaqueta la mayoría de los frameworks que necesitamos usar, spirng cloud se usa como microservicios y spring boot se usa como andamiaje, por lo que usar sping session es una buena opción.
pom.xml
<dependency>
<groupId>org.springframework.session</groupId>
<artifactId>spring-session-data-redis</artifactId>
<version>1.2.1.RELEASE</version>
</dependency>
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>2.8.1</version>
</dependency>
archivo de configuración de primavera
<bean id="redisHttpSessionConfiguration"
class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration">
<property name="maxInactiveIntervalInSeconds" value="600"/>
</bean>
<bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig">
<property name="maxTotal" value="100" />
<property name="maxIdle" value="10" />
</bean>
<bean id="jedisConnectionFactory"
class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory" destroy-method="destroy">
<property name="hostName" value="${redis_hostname}"/>
<property name="port" value="${redis_port}"/>
<property name="password" value="${redis_pwd}" />
<property name="timeout" value="3000"/>
<property name="usePool" value="true"/>
<property name="poolConfig" ref="jedisPoolConfig"/>
</bean>
web.xml
<filter>
<filter-name>springSessionRepositoryFilter</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
<filter-name>springSessionRepositoryFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Código de muestra
@Controller
@RequestMapping("/test")
public class TestController {
@RequestMapping("/putIntoSession")
@ResponseBody
public String putIntoSession(HttpServletRequest request, String username){
request.getSession().setAttribute("name", “leo”);
return "ok";
}
@RequestMapping("/getFromSession")
@ResponseBody
public String getFromSession(HttpServletRequest request, Model model){
String name = request.getSession().getAttribute("name");
return name;
}
}
El código anterior está bien. Configure la sesión de sping para almacenar datos de sesión basados en redis, y luego configure un filtro de sesión de primavera. En este caso, las operaciones relacionadas con la sesión serán manejadas por la sesión de primavera. Luego, en el código, use la operación de sesión nativa, que consiste en obtener datos de redis directamente en función de la sesión de primavera.
Hay muchas formas de implementar sesiones distribuidas. Acabo de hablar de dos formas más comunes. Tomcat + redis se usaba más comúnmente en los primeros días; en los últimos años, el reacoplamiento a tomcat se ha implementado a través de la sesión de primavera.