Après avoir révisé la séance d'aujourd'hui, j'ai une meilleure compréhension et j'ai également quelques doutes. S'il vous plaît, aidez-moi à l'analyser.
La première question est qu'en PHP, la session possède un mécanisme de garbage collection. Le principe est que le mécanisme de garbage collection peut être déclenché autant de fois que session_start
est déclenché. Ma question est donc la suivante : si ma session a dépassé 1440 secondes, mais que le recyclage n'est pas déclenché immédiatement, peut-être pas dans les 5 minutes, puis-je toujours obtenir les données de session à ce moment-là ?
La deuxième question concerne le principe d'expiration de session. Les livres disent tous qu'il est basé sur l'heure de modification du fichier de session. Mes questions sont les suivantes : 1) Lorsque je visite normalement un site Web, sans modifier les données de session, est-ce que je le quitte avec précision après 1440 secondes ? 2) Ou cela signifie-t-il qu'à chaque fois que j'actualise la page Web, le fichier de session sera modifié filemtime
? Quel est le principe d'exécution de la session.
Le troisième problème est le problème de configuration de session_set_save_handler
de PHP. Ce n'est qu'en sachant comment la session gère filemtime
que nous pouvons bien écrire session_set_sa. La méthode
, car si le read
dans ve_handlerfilemtime
est modifié à chaque actualisation de la page web, il doit être modifié dans read
filemtime
.
En principe, vous ne pouvez pas l'obtenir, car le code obtenu est lu via PHP, et le processus de lecture vérifiera à nouveau s'il a expiré. S'il expire, vous ne pourrez toujours pas l'obtenir.
1) L'heure configurée dans php.ini est précise et non invalide. La valeur par défaut est 1440. Vous pouvez modifier ce paramètre dans le programme, mais il est toujours recommandé de modifier le fichier de configuration. Pourquoi dit-on que le bien et le mal ne sont pas valides ? Parce que PHP n'est pas résident en mémoire, il doit utiliser chaque requête pour confirmer si certaines tâches planifiées sont déclenchées. La seconde raison est de réduire la perte de performances causée par chaque garbage collection. Les probabilités de garbage collection sont respectivement session.gc_probability et session.gc_pisor. gc_probability/gc_pisor est la probabilité. Par exemple, si elle est de 1/100, elle ne sera déclenchée qu'une seule fois pour au moins 100 requêtes.
2) Chaque fois qu'il est actualisé, l'heure du fichier changera.
Vue de l'implémentation de session du framework Laravel. Voici les formulaires de stockage de fichiers et de bases de données :
Aucun code associé similaire à l'actualisation du fichier n'a été trouvé.
Après le test, dans le cas du stockage de fichiers, définissez session.gc_maxlifetime sur 30 secondes. Si elle dépasse 30 secondes, les données de session peuvent toujours être libérées. Et lors du prochain cas d'actualisation, l'heure du fichier sera effectivement remplacée par l'heure actuelle.
Quelqu'un peut-il expliquer pourquoi et changer le stockage personnalisé en memcache ou la base de données sera-t-elle stockée dans le même format que le fichier ?