Apprenez Spring Session et Redis pour résoudre les problèmes de partage inter-domaines de sessions distribuées

Utilisez Spring Session et Redis pour résoudre le problème du partage multi-domaines de Session distribué

Explication du phénomène :

Le devant Les codes -end et back-end du projet ne le sont pas. Après la séparation, lorsque le service fonctionne normalement sur deux instances, une invite similaire à la nécessité de se reconnecter apparaîtra occasionnellement et le message d'erreur en arrière-plan

Il s'agit d'une exception de processeur. La raison n'est pas évidente

Après l'ajout d'une instance de machine, lors de l'accès à la page frontale, la page de connexion est consultée à plusieurs reprises, ce qui entraîne un accès répété à la page de connexion. à la page 302. Divers signes indiquent que cela est dû à des problèmes de configuration de connexion.

Recommandations de sujets connexes : session php (y compris des photos, des vidéos, des cas)

Introduction au problème : La session ne peut pas être partagée, ce qui entraîne une interrogation entre différentes machines nécessitant une connexion, ce qui entraîne une exception de service final

Solution : Utilisez Spring Session et Redis pour résoudre le problème des sessions distribuées partage de domaine

Résoudre la configuration :

1)Ajouter une dépendance

<dependency>
  <groupId>org.springframework.session</groupId>
  <artifactId>spring-session-data-redis</artifactId>
  <version>1.2.0.RELEASE</version>
</dependency>
<dependency>
  <groupId>org.apache.velocity</groupId>
  <artifactId>velocity</artifactId>
  <version>1.7</version>
</dependency>

2 ) Ajouter une configuration web.xml file:

<!-- 分布式Session共享Filter -->
<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>

3) Configuration Spring.xml

<!-- 将session放入redis -->
<context:annotation-config/>
<bean id="redisHttpSessionConfiguration"   class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration">
   <property name="maxInactiveIntervalInSeconds" value="120" />
</bean>
<bean class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory">
   <!-- redis 配置 -->
   <property name="hostName" value="192.168.0.48" />
   <property name="port" value="6379" />
</bean>

analyse :

1 Classe DelegatingFilterProxy dans le web : Elle appartient au proxy fiter, qui démarrera. chargement après le démarrage de Tomcat. Lors du filtrage dans web.xml, la gestion du filtre est confiée aux beans au printemps. Autrement dit, la troisième étape de la configuration introduit RedisHttpSessionConfiguration

2. . Cette classe est très importante. SpringHttpSessionConfiguration passe @Bean Inject springSessionRepositoryFilter dans le conteneur

3. que DelegatingFilterProxy a recherché plus tôt. SessionRepositoryFilter est la clé, comment sont-ils liés spécifiquement SessionRepositoryFilter

Si le paramètre init-param n'est pas spécifié, DelegatingFilterProxy utilisera le nom du filtre comme objet Bean à trouver, qui est également le rôle de la classe DelegatingFilterProxy. On peut voir que chaque requête passera par ce filtre, et les requêtes qui passeront par ce filtre passeront également par le filtre springSessionRepositoryFilter. Ensuite, nous examinerons le filtre

springSessionRepositoryFilter

4, La fonction consiste à remplacer le support javax.servlet.http.HttpSession par défaut du conteneur par

. Les principales méthodes et propriétés de SessionRepositoryFilterorg.springframework.session.SessionSessionRepositoryFilter sont les suivantes :

Parmi elles,

,

et SessionRepositoryResponseWrapper sont. classes internes. Ceci est également très important. Par exemple, la classe SessionRepositoryRequestWrapper SessionRepositoryRequestWrapperHttpSessionWrapper

peut être vue que SessionRepositoryRequestWrapper hérite de la classe javax.servlet.http.HttpServletRequestWrapper. Nous savons que l'implémentation par défaut de l'interface HttpServletRequest est HttpServletRequestWrapper, comme suit

6. Parce que SessionRepositoryRequestWrapper hérite de HttpServletRequestWrapper et que HttpServletRequestWrapper implémente l'interface HttpServletRequest, SessionRepositoryRequestWrapper réécrit certaines méthodes dans l'interface HttpServletRequest, il y a donc : getSession, changeSessionId, etc. . méthode. À ce stade, nous devons grosso modo comprendre que la demande et la réponse originales ont été reconditionnées. Nous comprenons également comment le HttpSeesion original a été remplacé par Spring Session.

Nous utilisons les touches de raccourci pour afficher l'implémentation spécifique de request.getSession(), et nous pouvons voir qu'il existe déjà une méthode pour remplacer SessionRepositoryRequestWrapper. Il existe deux implémentations par défaut ci-dessus, l'une est originale et l'autre est implémentée par Spring Session. Laquelle doit être sélectionnée comme implémentation ? C'est le rôle du proxy DelegatingFilterProxy que nous avons mentionné ci-dessus. Il filtrera chaque requête via DelegatingFilterProxy. passer également par le filtre springSessionRepositoryFilter. Le filtre springSessionRepositoryFilter réalise la conversion de la requête originale en SessionRepositoryRequestWrapper. Implémentation de

request.getSession().setAttribute(name, value) : En suivant le code, vous pouvez accéder au contenu ci-dessous

et vous pouvez voir les opérations liées à Redis ! À ce stade, nous devrions savoir comment fonctionne Spring Session ! Bien que le processus ci-dessous ne soit pas présenté à nouveau, il est déjà clairement compris.

Recommandations d'apprentissage associées : Tutoriel vidéo Redis

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!