Maison  >  Article  >  base de données  >  Détails de l'évolution de l'architecture MySQL de petite à grande

Détails de l'évolution de l'architecture MySQL de petite à grande

黄舟
黄舟original
2017-03-04 14:53:391013parcourir

Supposons qu'un site Web (discuz) ait un petit nombre de visites depuis le début jusqu'à des dizaines de millions de PV quotidiens. Spéculons sur l'évolution de son architecture de serveur mysql.

La première étape
Le niveau pv quotidien des visites du site Web est inférieur à 1w. Une seule machine exécute Web et db, et il n'est pas nécessaire de procéder à un réglage de la couche d'architecture (par exemple, il n'est pas nécessaire d'augmenter le cache Memcached). À l'heure actuelle, les données sont souvent sauvegardées quotidiennement, mais parfois, si la sécurité des données est prise en compte, un maître-esclave MySQL sera mis en place.

La deuxième phase
Le PV quotidien des visites du site Web a atteint des dizaines de milliers. À l'heure actuelle, la machine unique est déjà quelque peu chargée Nous devons séparer le Web et la base de données, et nous devons créer un service Memcached comme cache. En d'autres termes, à ce stade, nous pouvons également utiliser une seule machine pour exécuter MySQL afin d'effectuer le stockage des données et l'interrogation de l'ensemble du site Web. Si vous faites MySQL maître-esclave, le but est également la sécurité des données.

La troisième étape
Le PV quotidien des visites de sites Web a atteint des centaines de milliers. Bien qu'une seule machine puisse le prendre en charge, la configuration de la machine requise est bien meilleure que celle de la machine précédente. Si les fonds le permettent, vous pouvez acheter une machine avec une configuration élevée pour exécuter le service MySQL. Cependant, cela ne signifie pas que doubler la configuration doublera les performances. À un certain stade, augmenter la configuration n'entraînera plus une augmentation des performances. . Par conséquent, à ce stade, nous penserons au clustering des services MySQL, ce qui signifie que nous pouvons utiliser plusieurs machines pour exécuter MySQL. Cependant, les clusters MySQL sont différents des clusters Web. Nous devons prendre en compte la cohérence des données, nous ne pouvons donc pas simplement appliquer les méthodes de clustering Web (lvs, proxy nginx). L'architecture possible est mysql maître-esclave, un maître et plusieurs esclaves . Afin de garantir la robustesse de l'architecture et l'intégrité des données, il ne peut y avoir qu'un seul maître et plusieurs esclaves.

Il y a un autre problème auquel nous devons réfléchir, c'est-à-dire que dans la couche Web frontale, notre programme spécifie l'adresse IP de la machine MySQL. Ainsi, lorsqu'il y a plusieurs MySQL. machines, que se passe-t-il dans le programme ? discuz a en fait une fonction qui prend en charge la séparation en lecture et en écriture MySQL. Autrement dit, nous pouvons utiliser plusieurs machines pour exécuter MySQL, dont l'une est destinée à l'écriture et les autres à la lecture. Il nous suffit de configurer les adresses IP de lecture et d'écriture dans le programme, et le programme distinguera automatiquement les machines. Bien sûr, si nous n'utilisons pas la configuration fournie avec discuz, nous pouvons également utiliser un logiciel appelé mysql-proxy pour réaliser la séparation en lecture et en écriture. Il prend en charge le mode un maître et plusieurs esclaves.

La quatrième étape
Le nombre quotidien de visites sur les sites Internet atteint plusieurs millions. Le modèle précédent à un maître, plusieurs esclaves a rencontré des goulots d'étranglement, car lorsque le nombre de visites sur le site Web augmente, la quantité de lecture de la base de données augmente également. Nous devons ajouter plus d'esclaves, mais lorsque le nombre d'esclaves atteint des dizaines, cela est dû. vers le principal Tous les journaux bin doivent être distribués à tous les esclaves, ce processus lui-même est donc très fastidieux. Couplé à une lecture fréquente, il entraînera inévitablement un retard important dans la synchronisation des données depuis les esclaves. Par conséquent, nous pouvons faire une optimisation, changer le maître et les multiples esclaves d'origine de MySQL en un maître et un esclave, puis l'esclave servira de maître aux autres esclaves. L'ancien maître est uniquement responsable de l'écriture des affaires du site Web, et les esclaves suivants. Il n'est responsable d'aucune activité du site Web, mais est uniquement responsable de la synchronisation du bin-log avec d'autres esclaves. De cette façon, vous pouvez continuer à empiler plusieurs bibliothèques esclaves supplémentaires.

La cinquième étape
Lorsque le PV quotidien des visites du site Web a atteint 10 millions, nous avons constaté que le nombre d'écritures sur le site Internet Il est très volumineux. Il n'y avait qu'un seul maître dans notre architecture précédente, et le maître ici est devenu un goulot d'étranglement. Des ajustements supplémentaires sont donc nécessaires. Par exemple, nous pouvons diviser l'entreprise en modules, séparer ceux liés aux utilisateurs, séparer les autorisations, les points, etc., et exécuter une bibliothèque distincte, puis l'utiliser comme maître-esclave, ce qu'on appelle la sous-bibliothèque. . Bien entendu, vous pouvez également modifier la latitude, séparer les tables avec un volume d'accès ou d'écriture important et les exécuter sur un serveur. Vous pouvez également diviser une table en plusieurs petites tables. Cette étape de fonctionnement implique quelques changements de procédure, il est donc nécessaire de communiquer et de concevoir à l'avance avec les collègues de développement. En bref, ce que vous devez faire dans cette étape est de sous-base de données et sous-table.

Écrire au dos
Pour un développement ultérieur, continuez simplement à diviser la grande table en petites tables. Le site Web national Alibaba Taobao contient une énorme quantité de données. Toutes leurs bases de données sont MySQL. Leur architecture MySQL suit le principe des sous-bases de données et des sous-tables. Cependant, leurs règles de division auront de nombreuses latitudes, comme la division par région. peut être divisé en fonction des acheteurs et des vendeurs, peut être divisé en fonction du temps, etc.

Ce qui précède présente les détails du processus d'évolution de l'architecture MySQL de petite à grande. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !


Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn