Topologie répliquée
NCache La topologie répliquée garantit la continuité des données utilisateur, même en cas de panne simultanée de plusieurs serveurs. Dans un cluster, si tous les nœuds de serveur possèdent la même copie des données, la haute disponibilité est assurée. Autrement dit, le cluster peut survivre à la défaillance de quelques nœuds sans perte de données. Topologie répliquée Cela permet à l'utilisateur de disposer de plusieurs serveurs, chacun contenant une copie identique des données. Ainsi, chaque serveur est une réplique exacte des autres. Par conséquent, la défaillance simultanée de plusieurs serveurs n'entraîne aucune perte de données.
Réplication synchrone pour la cohérence des données
Chaque fois qu'un client effectue une opération d'écriture (ajoute, mises à jour, supprimeCette opération est diffusée à l'ensemble du cluster afin de la répliquer sur tous les serveurs de cache avant de rendre la main au client. Le serveur qui reçoit les opérations du client est responsable de leur diffusion. Au cours de ce processus, un jeton de séquence est tiré du serveur coordinateur et associée à l'opération en cours afin de garantir que cette opération soit effectuée sur tous les serveurs dans le même ordre pour assurer la cohérence des données.
Si une opération d'écriture diffusée échoue sur un serveur de cache, son échec est également diffusé sur tous les serveurs de cache pour supprimer ces données. Ceci est fait pour assurer la cohérence des données dans tout le cluster, ce qui signifie que si des données existent dans le cache, tous les serveurs ont les mêmes données.
Étant donné que la réplication est effectuée de manière synchrone, cette topologie n'est pas adaptée aux opérations d'écriture, car un plus grand nombre de serveurs nécessitent plus de temps pour que les données soient répliquées sur tous les serveurs de cache avant de rendre le contrôle à l'application d'écriture. Il est recommandé de limiter la taille du cluster à 3 serveurs si vous ne souhaitez pas subir de dégradation des performances des opérations d'écriture.
Rôle du serveur coordinateur
Le serveur coordinateur (le nœud serveur le plus ancien) effectue plusieurs tâches comme Transfert d'État, Opérations d'écriture différée, les invalidations de données comme ExpirationAprès avoir décidé de supprimer un élément du cache, il demande à tous les autres nœuds de le supprimer également de leur cache. serveur coordinateur lorsque le serveur sortant du cluster devient le serveur le plus ancien suivant. serveur coordinateur et reprend ses responsabilités.
Évolutivité linéaire pour les opérations de lecture
Comme tous les serveurs ont les mêmes données, les clients sont répartis entre tous les serveurs de cache. Ainsi, chaque serveur fournit les mêmes données aux clients. Plus de serveurs dans le cluster signifient que plus de demandes de lecture de données sont traitées simultanément.
Équilibrage de charge de connexion
La topologie répliquée a une fonction spéciale pour connexions client à équilibrage automatique entre les serveurs pour partager la charge de données entre les serveurs de cache. Lorsqu'un client se connecte à un serveur, ce serveur vérifie que tous les autres nœuds du serveur ont également le même nombre de clients. Si d'autres serveurs ont moins de clients, il rejette gracieusement la demande de connexion client et la redirige vers les autres serveurs. De cette façon, tous les serveurs ont le même nombre de clients et aucun serveur n'est surchargé de clients par rapport aux autres serveurs de cache.
Connectivité client
Dans la topologie répliquée, un client n'est connecté qu'à un seul serveur d'un cluster à la fois. Si le serveur connecté tombe en panne, le client se connecte automatiquement à un autre serveur du cluster sans aucune intervention humaine.
Synchronisation des données et transfert d'état
Un transfert d'état est déclenché lorsqu'un nœud rejoint ou quitte le cluster. Pendant un transfert d'état, aucun autre nœud ne peut rejoindre ou quitter le cluster.
Cette restriction s'applique à tous les nœuds, même ceux qui ne participent pas directement au transfert d'état. Par exemple, dans un cluster à trois nœuds, si le nœud 3 est en cours de transfert d'état, le nœud 2 ne peut pas quitter le cluster tant que le transfert d'état du nœud 3 n'est pas terminé. De même, aucun nœud supplémentaire ne peut rejoindre le cluster tant que le transfert d'état en cours n'est pas terminé.
Lorsqu'un transfert d'état est déclenché par le départ d'un nœud, le processus est minimal car tous les nœuds conservent déjà des données identiques. En revanche, lorsqu'un nouveau nœud rejoint le cluster, il doit synchroniser son cache avec le reste du cluster. Pour ce faire, le nœud nouvellement rejoint demande l'ensemble des données mises en cache au serveur coordinateur. Étant donné que tous les transferts d'état sont gérés par le coordinateur, celui-ci conserve les informations nécessaires à la bonne synchronisation de chaque nœud.
