Avantages et inconvénients de la stratégie de blancing D'affinité Session / Session?
une approche pour une évolutivité élevée est d'utiliser l'équilibrage de charge réseau pour partager la charge de traitement entre plusieurs serveurs.
un des défis que cette approche présente est lorsque les serveurs sont État aware-état de stockage utilisateur dans une"session".
une solution à ce problème est "sticky session" (alias "session affinity") où chaque utilisateur est assigné à un seul serveur et ses données d'état sont contenues sur ce serveur exclusivement pendant toute la durée de la session.
Quels sont les avantages et les Inconvénients de la "collante session"? Avez-vous l'utiliser et si oui, êtes-vous satisfait?
1 réponses
Avantages:
- c'est facile-- aucun changement d'application requis.
- utilise mieux les caches RAM locales (par exemple, recherche du profil de l'utilisateur une fois, le cache, et peut le réutiliser lors de visites ultérieures du même utilisateur)
contre:
- si le serveur tombe en panne, la session est perdue. (notez qu'il s'agit d'une commande de stockage des informations de session localement sur le serveur web-- et non de sessions collantes en soi). si ce qui est dans la session est très important pour l'utilisateur (par exemple un brouillon d'e-mail) ou pour le site (par exemple un panier d'achat) alors perdre un de vos serveurs peut être très douloureux.
- selon l'implémentation "sticky" dans votre équilibreur de charge, peut diriger la charge inégale vers certains serveurs par rapport à d'autres
- mettre un nouveau serveur en ligne ne donne pas immédiatement beaucoup de charge au nouveau serveur-- si vous avez un système d'équilibrage de charge dynamique pour faire face aux pointes, la rigidité peut ralentir votre capacité à répondre rapidement à une pointe. Cela dit, il s'agit en quelque sorte d'un cas d'exception qui ne s'applique qu'aux sites très grands et sophistiqués.
- si vous avez relativement peu d'utilisateurs mais que le trafic d'un seul utilisateur peut inonder un serveur (par exemple, pages Complexes avec SSL, AJAX, images générées dynamiquement, compression dynamique, etc.), puis stickines peut nuire au temps de réponse de l'utilisateur final puisque vous ne répartissez pas la charge d'un seul utilisateur uniformément sur les serveurs. Si vous avez beaucoup d'utilisateurs simultanés, ce n'est pas un problème puisque tous vos les serveurs seront submergés!
mais si vous devez utiliser l'état de session server-local, les sessions sticky sont définitivement la bonne voie à suivre-- et même si vous n'utilisez pas l'état de session server-local, la rigidité a des avantages quand il s'agit de l'utilisation du cache (voir ci-dessus). Votre équilibreur de charge devrait être en mesure de regarder les cookies HTTP (pas seulement l'adresse IP) pour déterminer la rigidité, puisque les adresses IP peuvent changer au cours d'une seule session (par exemple, l'arrimage d'un ordinateur portable entre un filaire et un sans-fil réseau.)
encore mieux, n'utilisez pas l'état de session sur le serveur web! Si l'état de la session est très douloureux à perdre (par exemple les chariots de magasinage), stockez-le dans une base de données centrale et supprimez périodiquement les anciennes sessions. Si l'état de la session n'est pas critique (par exemple, Nom d'utilisateur/URL avatar), alors insérez-le dans un cookie-- assurez-vous simplement de ne pas y insérer trop de données.
versions modernes des Rails, par défaut, stockent les variables de session dans un cookie pour les raisons ci-dessus. D'autres cadres web peuvent avoir une option "stocker dans le cookie" et/ou "stocker dans la base de données".