Est-il sûr de stocker des sessions avec Redis?


92

J'utilise actuellement MySql pour stocker mes sessions. Cela fonctionne très bien, mais c'est un peu lent.

On m'a demandé d'utiliser Redis, mais je me demande si c'est une bonne idée car j'ai entendu dire que Redis retardait les opérations d'écriture. J'ai un peu peur car les sessions doivent être en temps réel.

Quelqu'un at-il rencontré de tels problèmes?


1
Puisque Redis dit qu'il a une durabilité optionnelle, alors je dirais qu'il est sûr de l'utiliser si vous optez pour la persistance sur le disque dur. Cependant, pour les données de session - je les enregistrerais certainement dans la RAM (ce qui signifie que je ne m'inquiéterais pas de la durabilité de l'ensemble de l'épreuve). Le pire qui devrait arriver en cas de perte de données de session est de déconnecter vos utilisateurs.
NB

1
oui mais cela fait partie de mon exigence, les utilisateurs ne devraient pas avoir à se reconnecter, car certaines données des utilisateurs sont conservées pendant toute la session alors que les utilisateurs ne sont pas connectés (utilisateurs invités). Ils opteront pour la RAM Redis mais avec la journalisation et / ou la sauvegarde activée. Si nous perdons certaines sessions, c'est acceptable.
Trent

1
mes principales préoccupations concernent l'écriture retardée, que se passe-t-il si un utilisateur se connecte et que la session est écrite avec retard, il sera redirigé mais pas connecté
Trent

2
imaginez un site de commerce électronique, si la session est perdue, le panier actuel est également perdu, ce n'est pas terrible mais cela peut être étrange pour les utilisateurs. Les utilisateurs invités sont identifiés uniquement avec une session, il n'y a donc aucun moyen de récupérer leur panier.
Boris Guéry

1
@ BorisGuéry - ce n'est pas que je ne suis pas d'accord, mais s'il faut booster les performances - il faut faire des compromis en cas de problème. Oui, il sera étrange que les utilisateurs se déconnectent soudainement, c'est sûr - mais la question est de savoir à quelle fréquence cela devrait-il se produire? Si c'est une ou deux fois par an que tous les nœuds Redis tombent en panne, je ne vois aucune raison de décimer les performances pendant quelques périodes isolées lorsque l'ensemble du cluster est indisponible. Mais ce n'est que moi.
NB

Réponses:


147

Redis est parfait pour stocker des sessions. Toutes les opérations sont effectuées en mémoire, et les lectures et écritures seront donc rapides.

Le deuxième aspect est la persistance de l'état de session. Redis vous offre une grande flexibilité dans la manière dont vous souhaitez conserver l'état de session sur votre disque dur. Vous pouvez passer par http://redis.io/topics/persistence pour en savoir plus, mais à un niveau élevé, voici vos options -

  1. Si vous ne pouvez pas vous permettre de perdre des sessions, définissez-le appendfsync alwaysdans votre fichier de configuration. Avec cela, Redis garantit que toutes les opérations d'écriture sont enregistrées sur le disque. L'inconvénient est que les opérations d'écriture seront plus lentes.
  2. Si vous êtes d'accord avec la perte d'environ 1 s de données, utilisez appendfsync everysec. Cela donnera d'excellentes performances avec des garanties de données raisonnables

14

Fondamentalement, il existe deux types principaux disponibles: les snapsnots asynchrones et fsync(). Ils sont appelés respectivement RDB et AOF. Plus d'informations sur les modes de persistance sur la page officielle .

La gestion du signal du processus démonisé se synchronise sur le disque lorsqu'il reçoit un SIGTERM par exemple, de sorte que les données seront toujours là après un redémarrage. Je pense que le démon ou le système d'exploitation doit se bloquer avant de voir une corruption d'intégrité, même avec les paramètres par défaut (instantanés RDB).

Le paramètre AOF utilise un fichier Ajouter uniquement qui consigne les commandes reçues par le serveur et recrée la base de données à partir de zéro lors du démarrage à froid, à partir du fichier enregistré. La politique de synchronisation de disque par défaut est de vider une fois toutes les secondes (IIRC) mais peut être définie pour verrouiller et écrire sur chaque commande.

L'utilisation à la fois des instantanés et du journal incrémentiel semble offrir à la fois une approche à long terme qui ne me dérange pas si je manque quelques secondes de données avec un journal incrémentiel plus sécurisé, mais coûteux. Redis prend en charge le clustering prêt à l'emploi, de sorte que la réplication peut également être effectuée.

J'utilise moi-même le paramètre RDB par défaut et j'enregistre les instantanés sur un FTP distant. Je n'ai pas encore vu de panne ayant causé une perte de données. Une panne matérielle aiguë ou une panne de courant serait très probable, mais je suis hébergé sur un VPS. Mince chance que cela se produise :)


12

Cette question concerne vraiment les sessions en temps réel, et semble avoir été soulevée en partie à cause d'un malentendu de l'expression `` opérations d'écriture retardée ''. Alors que les détails ont finalement été taquinés dans les commentaires, je voulais juste que ce soit super-duper clair. ..

Vous n'aurez aucun problème à implémenter des sessions en temps réel.

Redis est un en mémoire mémoire de valeur clé avec persistance en option sur le disque. Les «opérations d'écriture retardées» font référence aux écritures sur le disque , et non à la base de données en général, qui existe en mémoire. Si vous définissez une paire clé / valeur, vous pouvez l'obtenir immédiatement (c'est-à-dire en temps réel). La politique que vous sélectionnez en ce qui concerne la persistance (combien vous retardez les écritures) déterminera la limite supérieure de la quantité de données pouvant être perdue en cas de panne.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.