Position actuelle: Accueil> Derniers articles> Session_register_shutdown peut-il toujours déclencher dans l'environnement NGINX + PHP-FPM?

Session_register_shutdown peut-il toujours déclencher dans l'environnement NGINX + PHP-FPM?

M66 2025-05-31

Dans le mécanisme de gestion de session de PHP, la fonction Session_Register_Shutdown () est une fonction relativement nouvelle. Il est utilisé pour enregistrer une fonction de rappel et est automatiquement appelé lorsque le script est exécuté et que la session est fermée. L'intention initiale de ce mécanisme est de s'assurer qu'à la fin de la demande, toutes les modifications de $ _Session peuvent être réévaluées en toute sécurité, évitant ainsi la perte de données de session en raison des exceptions de script ou de la sortie précoce.

Cependant, dans les environnements de production réels, en particulier dans les architectures de déploiement tels que Nginx + PHP-FPM, si Session_register_Shutdown () peut garantir qu'elle sera toujours déclenchée à la fin de la demande est devenue une question qui mérite d'être discutée.

1. Mécanisme de travail de session_register_shutdown ()

PHP enregistre en interne un crochet "Close Session" à Session_Start () , qui est responsable de la rédaction des données de session à la fin de l'exécution du script. session_register_shutdown () permet aux utilisateurs de personnaliser les fonctions de rappel et de les ajouter à ce processus d'exécution.

Exemple de code:

 <?php
session_start();

session_register_shutdown(function() {
    // Ceci sera exécuté à la fin du script,Répondre session
    error_log('Session shutdown callback triggered.');
    // Vous pouvez opérer en toute sécurité ici $_SESSION
});
$_SESSION['count'] = ($_SESSION['count'] ?? 0) + 1;

echo "Nombre de visites:" . $_SESSION['count'];
?>

2. L'impact de l'environnement Nginx + PHP-FPM sur cette fonction

2.1 Mode de travail PHP-FPM

PHP-FPM est le FastCGI Process Manager pour PHP, et ses principales fonctionnalités sont:

  • Il s'exécute indépendamment du serveur Web et accepte les demandes de Nginx.

  • Les ressources seront recyclées une fois la demande terminée, mais le processus lui-même survit depuis longtemps.

Cela détermine que le cycle de vie de PHP est basé sur les unités de demande, et toutes les actions de nettoyage liées à la demande seront déclenchées à la fin de la demande.

2.2 Est-il toujours déclenché?

Dans le processus de demande normal, qu'il s'agisse d'un rappel enregistré via session_register_shutdown () ou le crochet de fermeture automatique de session de PHP lui-même, il sera exécuté.

Cependant, les circonstances particulières suivantes peuvent entraîner le déclenchement du rappel:

  • Le script PHP sort anormalement : par exemple, si exit () , die () est appelé ou le script est interrompu en raison d'une erreur mortelle, auquel cas, bien que la plupart des fonctions de nettoyage soient toujours exécutées, certains environnements de fonctionnement anormaux peuvent entraîner l'exécution du crochet.

  • La demande est forcée d'être résiliée par NGINX ou PHP-FPM : si le processus est expiré ou si le processus est tué manuellement, ce qui entraîne le non-exécuté du script PHP.

  • Exception de communication de FastCGI : Si la demande est fermée ou réessayante, le processus PHP ne termine pas le processus d'exécution normalement.

  • Fastcgi_finish_request () est utilisé : cette fonction mettra fin à la réponse de la demande à l'avance, et le code suivant sera toujours exécuté, mais si le crochet dépend de la fin de la demande, le moment peut être inexact.

Par conséquent, bien que session_register_shutdown () soit déclenché dans la plupart des cas, il n'est pas garanti d'être exécuté à 100% à la fin de la demande.

3. Suggestions et meilleures pratiques

  • Évitez de compter sur session_register_shutdown () pour terminer la logique commerciale clé : les opérations de rédaction de données de session importantes doivent être complétées autant que possible au milieu de la demande ou dans le script explicitement.

  • Coopérez avec le mécanisme de gestion des erreurs : utilisez Register_Shutdown_Function () et le mécanisme de capture des erreurs pour éviter la perte de données due à l'interruption d'exception.

  • Définissez raisonnablement les paramètres de délai d'expiration PHP et NGINX : Évitez l'interruption forcée des demandes et assurez-vous que le script est exécuté normalement.

  • Exceptions de simulation de l'environnement de test : Vérifiez la fiabilité de l'exécution du rappel et assurez la robustesse de l'application.

4. Exemple de référence

Voici un exemple simplifié combinant session_register_shutdown () et la gestion des exceptions:

 <?php
session_start();

session_register_shutdown(function() {
    error_log('Session shutdown callback executed.');
    session_write_close();
});

register_shutdown_function(function() {
    $error = error_get_last();
    if ($error !== null) {
        error_log('Fatal error captured: ' . print_r($error, true));
        // Voici quelques opérations de réparation,Par exemple, journalisation ou alerte
    }
});

try {
    $_SESSION['user'] = 'Alice';
    // Simuler des exceptions
    // throw new Exception("Something went wrong!");
} catch (Exception $e) {
    error_log('Exception caught: ' . $e->getMessage());
    // Logique de gestion des exceptions
}

echo "Session updated.";
?>