Solution Redis à données uniques, multi-sources et à ultra-haute simultanéité

Redis est actuellement la base de données de cache KV la plus populaire. Elle est simple à utiliser, sûre et stable, et possède une très large gamme d'applications dans l'industrie Internet.

Cet article partage principalement avec vous les solutions et solutions de Redis sous l'accès simultané ultra-élevé de données uniques et de sources multiples.

Avant-propos

Redis résout principalement deux problèmes :

Lorsque vous rencontrez un scénario commercial avec des dizaines de millions d'utilisateurs quotidiens et des millions de personnes en même temps en ligne, si l'accès frontal est directement chargé dans la base de données back-end, cela peut submerger la base de données sous-jacente et entraîner l'arrêt de l'activité. Ou, à mesure que le nombre de conditions de requête augmente et que les conditions de combinaison deviennent plus complexes, le temps de réponse des résultats de la requête ne peut pas être garanti, ce qui entraîne une baisse de l'expérience utilisateur et une perte d'utilisateurs. Afin de résoudre des scénarios commerciaux à forte concurrence et à faible latence, Redis a vu le jour.

Examinons deux scénarios ci-dessous

Il s'agit d'un scénario commercial pour la recherche d'un logement en ligne. Il y a tellement de conditions de requête que le backend doit être complexe. Requête SQL, est-il nécessaire d'utiliser Redis dans ce scénario ?

La réponse est non. En raison de la faible concurrence dans le secteur de la recherche de maisons en ligne, les clients ne sont pas si exigeants en matière de temps de réponse. La plupart des requêtes peuvent être directement interrogées temporairement via SQL dynamique. Bien entendu, afin d'améliorer l'expérience utilisateur, certains résultats de requêtes chaudes peuvent être pré-mis en cache dans Redis pour améliorer l'expérience utilisateur.

Regardons à nouveau ce scénario

Le système de vérification de films pour les demandes vidéo a presque le même scénario commercial que le système de recherche de logement, mais le la concurrence est plus élevée De plusieurs ordres de grandeur, ce scénario est très approprié pour utiliser Redis comme cache pour augmenter l'accès simultané, réduire le temps de réponse et répondre à des centaines de milliers, voire des millions d'exigences d'accès simultané. On peut voir que les facteurs fondamentaux pour décider d'utiliser ou non Redis sont les exigences de concurrence et de latence.

Voyons comment Redis résout les exigences d'accès simultané dans des scénarios Internet extrêmes.

Solution de mise en cache sous accès simultané ultra-élevé

Il s'agit d'un schéma d'architecture de cache multimédia typique. Le système de publication met à jour la médiathèque de temps en temps, via Le service de cache distribué synchronise chaque dernier article avec le cache Redis et l'application frontale trouve l'accès à la source de données correspondante via la couche de routage. Les données de chaque service de cache sont désynchronisées. Lorsqu'un événement de point d'accès se produit, la couche de routage peut acheminer l'accès depuis des zones inaccessibles vers le serveur de cache où se trouvent les données du point d'accès, provoquant une augmentation instantanée du trafic. Dans des cas extrêmes, cela peut entraîner une indisponibilité du serveur et des dommages à l'entreprise. Alors, comment résoudre ce scénario d’explosion de trafic irrégulier ?

Voici quelques idées :

Divisez les clés de hotspot avec des préfixes pour réaliser une réplication de données à chaud

Ajoutez un cache local au couche de routage, améliore les capacités de mise en cache grâce à la mise en cache à plusieurs niveaux

La couche de cache fournit des copies de données et améliore les capacités d'accès simultané

La première solution peut dissiper efficacement les données chaudes, mais les événements chauds se produisent de manière aléatoire et irrégulière . La pression d'exploitation et de maintenance est élevée et le coût est élevé. Ce n'est qu'une solution pour résoudre le mal de tête et le problème.

La deuxième solution peut améliorer les capacités de mise en cache en ajoutant un cache local. Cependant, la taille du cache local doit être définie, la fréquence de rafraîchissement et la capacité de l'entreprise à tolérer des lectures sales sont autant de problèmes inévitables.

La troisième solution peut ajouter des répliques en lecture seule pour réaliser la réplication des données, mais elle entraînera également des coûts élevés et une charge élevée sur la base de données principale.

Le diagramme d'architecture ci-dessus est une solution optimisée. Il extrait plusieurs branches de bibliothèques esclaves en lecture seule via la bibliothèque principale et divise les caches indépendants pour différentes sources de requêtes Serve. Par exemple, les applications mobiles sont acheminées de manière fixe vers le groupe de ressources de données APP, et l'accès WEB est acheminé vers le groupe de ressources de données WEB, etc., et chaque groupe de ressources peut fournir N copies en lecture seule pour améliorer les capacités d'accès simultané sous la même origine. accéder. Cette architecture peut améliorer les capacités d'isolation des ressources de différentes sources d'accès et améliorer la stabilité et la disponibilité des services sous accès multi-sources.

Les problèmes de cette solution sont également évidents :

La bibliothèque principale a de mauvaises performances de lecture et d'écriture

Il existe de nombreuses répliques en lecture seule et le coût est élevé

Le lien en lecture seule est transmis. Il est long, difficile à gérer et à entretenir, et entraîne des coûts d'exploitation et de maintenance élevés

L'exemple le plus exagéré de nos clients a utilisé un 1 maître 40 lectures. une architecture uniquement pour répondre à des scénarios commerciaux similaires.

Comment Alibaba Cloud Redis résout-il ce problème d'accès simultané ultra élevé ?

Alibaba Cloud a lancé une version de Redis aux performances améliorées. En améliorant les capacités de traitement simultané des E/S du réseau, il a considérablement amélioré les performances de lecture et d'écriture du nœud unique Redis. la version communautaire, les performances ont été améliorées 3 fois. Grâce au maintien du mode de traitement Single Worker, il est 100 % compatible avec le protocole Redis. La capacité d'accès ci-dessus d'un million de QPS pour une seule donnée peut être facilement atteinte. Le scénario multimédia présenté dans cet article peut atteindre plus de 2 millions de QPS pour une seule donnée en activant les instances en lecture seule version 1 master 5 aux performances améliorées, atténuant ainsi efficacement l'augmentation du trafic causée par des événements chauds soudains, un accès simultané ultra-élevé et d'autres industries. points douloureux. Par rapport à la version communautaire auto-construite avec 1 maître et 40 lectures, la version améliorée aux performances d'Alibaba Cloud Redis avec les mêmes normes de performances a une architecture à 1 maître et 5 lectures seules, qui est plus stable, plus pratique à gérer, et plus encore. pratique à utiliser.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!