【MySQL】Contrôle de concurrence

Chaque fois que plusieurs requêtes doivent modifier des données en même temps, des problèmes de contrôle de concurrence surviendront. Nous discutons ici du contrôle de concurrence de MySQL à deux niveaux : la couche serveur et la couche moteur de stockage. Le contrôle de la concurrence est un sujet très vaste, et il existe une grande quantité de littérature théorique qui en discute en détail. Ici, nous discutons seulement brièvement de la manière dont MySQL contrôle la lecture et l'écriture simultanées.

Prenons l'exemple de la boîte e-mail du système Unix. Le format de fichier mbox typique est très simple. Tous les e-mails d'une boîte aux lettres mbox sont sérialisés ensemble et connectés de bout en bout. Ce format est très convivial pour la lecture et les informations des e-mails Feixi, et il est également facile de transmettre des e-mails. Il suffit d'ajouter le nouveau contenu de l'e-mail à la fin du fichier.

Mais que se passe-t-il si deux processus livrent le courrier dans la même boîte aux lettres en même temps ? Évidemment, les données de la boîte aux lettres seront détruites et le contenu des deux e-mails sera ajouté à la fin du fichier de la boîte aux lettres. Un système de distribution de boîtes aux lettres bien conçu utilise des verrous pour empêcher la corruption des données. Si un client tente de livrer du courrier et que la boîte aux lettres est verrouillée par un autre client, il doit attendre que le verrou soit libéré avant que la livraison puisse avoir lieu.

Bien que ce schéma de verrouillage fonctionne bien dans les environnements d'application réels, il ne prend pas en charge le traitement simultané. Etant donné qu'à tout moment, un seul processus peut modifier les données de la boîte aux lettres, il s'agit d'un problème dans les systèmes de boîtes aux lettres de grande capacité.

Verrouillage en lecture-écriture

Il n'y a aucun problème de ce type lors de la lecture des données de la boîte aux lettres, même si plusieurs utilisateurs lisent simultanément en même temps, il n'y aura aucun problème. Puisque la lecture ne modifie pas les données, il n’y a pas d’erreur. Mais que se passe-t-il si un client lit la boîte aux lettres tandis qu'un autre utilisateur tente de supprimer l'e-mail numéro 25 ? La conclusion est incertaine. Le client qui lit peut se terminer avec une erreur ou ne pas être en mesure de lire des données cohérentes de la boîte aux lettres. Ainsi, pour des raisons de sécurité, même la lecture de la boîte aux lettres nécessite une attention particulière.

Si vous traitez la boîte aux lettres ci-dessus comme une table dans la base de données et l'e-mail comme une ligne dans la table, il est facile de voir que le même problème existe toujours. À bien des égards, une boîte aux lettres est une simple table de base de données. La modification d'enregistrements dans une table de base de données est très similaire à la suppression ou à la modification d'informations de courrier électronique dans une boîte aux lettres.

La solution à ce type de problème classique est le contrôle de concurrence (verrous en lecture et verrous en écriture). En fait, c'est très simple. Lorsqu'il s'agit de lecture ou d'écriture simultanée, le problème peut être résolu en implémentant un système de verrouillage composé de deux types de verrous. Ces deux types de verrous sont généralement appelés verrouillage partagé et verrouillage exclusif , également appelé verrouillage en lecture et verrouillage en écriture .

Ne discutons pas ici de la manière de l'implémenter. Décrivons le concept de verrouillage comme suit : les verrous en lecture sont partagés, ou ils ne se bloquent pas. Plusieurs clients peuvent lire la même ressource en même temps sans interférer les uns avec les autres. Les verrous d'écriture sont exclusifs, ce qui signifie qu'un verrou d'écriture bloquera d'autres verrous d'écriture et de lecture. Ce n'est qu'ainsi que l'on peut garantir qu'un seul utilisateur peut effectuer des écritures à un moment donné. empêcher d'autres utilisateurs de lire la même ressource en cours d'écriture.

Dans un système de base de données réel, le verrouillage se produit à chaque instant Lorsqu'un utilisateur modifie une certaine partie des données, MySQL empêchera les autres utilisateurs de lire les mêmes données via le verrouillage. La plupart du temps, la gestion interne des verrous MySQL est transparente.

Granarité du verrouillage

Une façon d'assurer la concurrence sur les ressources partagées consiste à rendre le verrouillage des objets plus sélectif. Essayez de verrouiller uniquement une partie des données qui doivent être modifiées, plutôt que toutes les ressources. Une approche plus idéale consiste à verrouiller précisément uniquement les éléments de données qui seront modifiés (en particulier, verrouiller les champs modifiés). A tout moment, sur une ressource donnée, plus la quantité de données verrouillées est faible, plus la concurrence du système est élevée, à condition qu'il n'y ait pas de conflit entre elles.

Le problème est que le verrouillage consomme également des ressources. Diverses opérations de verrouillage, notamment l'acquisition du verrou, la vérification si le verrou a été libéré, la libération du verrou, etc., augmenteront la surcharge du système. Si le système passe beaucoup de temps à gérer les verrous au lieu d'accéder aux données, les performances du système peuvent en souffrir.

La stratégie dite de verrouillage consiste à rechercher un équilibre entre la surcharge de verrouillage et la sécurité des données. Cet équilibre affectera bien sûr les performances. La plupart des systèmes de bases de données commerciales n'offrent pas plus d'options et imposent généralement des verrous au niveau des lignes. la table et les implémente de diverses manières complexes pour fournir de meilleures performances autant que possible lorsqu'il y a de nombreux verrous.

MySQL offre une variété d'options, et chaque moteur de stockage MySQL peut implémenter sa propre stratégie de verrouillage et sa propre granularité de verrouillage. La gestion des verrous est une décision très importante dans la conception d’un moteur de stockage. Fixer la granularité du verrouillage à un certain niveau peut offrir de meilleures performances pour certains scénarios d'application. Mais les collègues perdront une bonne prise en charge pour d’autres scénarios d’application. Heureusement, MySQL prend en charge plusieurs architectures de moteur de stockage, il n'est donc pas nécessaire d'avoir une solution universelle unique. Les deux stratégies de verrouillage les plus importantes sont présentées ci-dessous.

Verrouillage de table (verrouillage de table)

Le verrouillage de table est la stratégie de verrouillage la plus basique dans MySQL, et c'est la stratégie avec la plus petite surcharge . Le verrouillage de la table est très similaire au mécanisme de verrouillage de la boîte aux lettres décrit précédemment : il verrouille la table entière. Avant qu'un utilisateur puisse effectuer des opérations d'écriture (insertion, suppression, mise à jour, etc.) sur la table, il doit obtenir un verrou en écriture. Cela bloquera toutes les opérations de lecture et d'écriture sur la table par d'autres utilisateurs. Ce n'est que lorsqu'il n'y a pas de verrou en écriture que les autres utilisateurs en lecture peuvent obtenir le verrou en lecture, et les verrous en lecture ne se bloquent pas les uns les autres.

Les verrous de table peuvent également avoir de bonnes performances dans certains scénarios. Par exemple, les verrous de table locaux en lecture prennent en charge certains types d’opérations d’écriture simultanées. De plus, les verrous en écriture ont également une priorité plus élevée que les verrous en lecture, de sorte qu'une demande de verrou en écriture peut être insérée devant la file d'attente des verrous en lecture (un verrou en écriture peut être inséré devant un verrou en lecture dans la file d'attente des verrous, alors qu'un verrou en lecture le verrou ne peut pas être inséré) devant le verrou en écriture).

Bien que le moteur de stockage puisse gérer ses propres verrous, Mysql lui-même utilise toujours une variété de verrous de table efficaces pour atteindre différents objectifs. Par exemple, le serveur utilise des verrous de table pour des instructions telles que alter table, ignorant le mécanisme de verrouillage du moteur de stockage.

[Remarque : le mécanisme de verrouillage est géré par le moteur de stockage, mais MySQL lui-même gérera parfois de force ce mécanisme de verrouillage]

Verrouillage de ligne (verrouillage de ligne)

Les verrous au niveau des lignes peuvent prendre en charge le traitement simultané dans la plus grande mesure (mais entraînent également la plus grande surcharge de verrouillage) . Il est bien connu que le verrouillage au niveau des lignes est implémenté dans InnoDB et XtraDB, ainsi que dans certains autres moteurs de stockage. Les verrous au niveau des lignes ne sont implémentés qu'au niveau de la couche moteur de stockage , et la couche serveur MySQL (si nécessaire, veuillez consulter le schéma d'architecture logique dans l'article précédent) n'est pas implémentée. La couche serveur n'a aucune connaissance de l'implémentation du verrouillage dans le moteur de stockage. Au fur et à mesure que nous poursuivons dans ce chapitre et tout au long du livre, tous les moteurs de stockage présentent des mécanismes de verrouillage à leur manière.

Chaque fois que plusieurs requêtes doivent modifier des données en même temps, des problèmes de contrôle de concurrence surviendront. Nous discutons ici du contrôle de concurrence de MySQL à deux niveaux : la couche serveur et la couche moteur de stockage. Le contrôle de la concurrence est un sujet très vaste, et il existe une grande quantité de littérature théorique qui en discute en détail. Ici, nous discutons seulement brièvement de la manière dont MySQL contrôle la lecture et l'écriture simultanées.

Prenons l'exemple de la boîte e-mail du système Unix. Le format de fichier mbox typique est très simple. Tous les e-mails d'une boîte aux lettres mbox sont sérialisés ensemble et connectés de bout en bout. Ce format est très convivial pour la lecture et les informations des e-mails Feixi, et il est également facile de transmettre des e-mails. Il suffit d'ajouter le nouveau contenu de l'e-mail à la fin du fichier.

Mais que se passe-t-il si deux processus livrent le courrier dans la même boîte aux lettres en même temps ? Évidemment, les données de la boîte aux lettres seront détruites et le contenu des deux e-mails sera ajouté à la fin du fichier de la boîte aux lettres. Un système de distribution de boîtes aux lettres bien conçu utilise des verrous pour empêcher la corruption des données. Si un client tente de livrer du courrier et que la boîte aux lettres est verrouillée par un autre client, il doit attendre que le verrou soit libéré avant que la livraison puisse avoir lieu.

Bien que ce schéma de verrouillage fonctionne bien dans les environnements d'application réels, il ne prend pas en charge le traitement simultané. Etant donné qu'à tout moment, un seul processus peut modifier les données de la boîte aux lettres, il s'agit d'un problème dans les systèmes de boîtes aux lettres de grande capacité.

Verrouillage en lecture-écriture

Il n'y a aucun problème de ce type lors de la lecture des données de la boîte aux lettres, même si plusieurs utilisateurs lisent simultanément en même temps, il n'y aura aucun problème. Puisque la lecture ne modifie pas les données, il n’y a pas d’erreur. Mais que se passe-t-il si un client lit la boîte aux lettres tandis qu'un autre utilisateur tente de supprimer l'e-mail numéro 25 ? La conclusion est incertaine. Le client qui lit peut se terminer avec une erreur ou ne pas être en mesure de lire des données cohérentes de la boîte aux lettres. Ainsi, pour des raisons de sécurité, même la lecture de la boîte aux lettres nécessite une attention particulière.

Si vous traitez la boîte aux lettres ci-dessus comme une table dans la base de données et l'e-mail comme une ligne dans la table, il est facile de voir que le même problème existe toujours. À bien des égards, une boîte aux lettres est une simple table de base de données. La modification d'enregistrements dans une table de base de données est très similaire à la suppression ou à la modification d'informations de courrier électronique dans une boîte aux lettres.

La solution à ce type de problème classique est le contrôle de concurrence (verrous en lecture et verrous en écriture). En fait, c'est très simple. Lorsqu'il s'agit de lecture ou d'écriture simultanée, le problème peut être résolu en implémentant un système de verrouillage composé de deux types de verrous. Ces deux types de verrous sont généralement appelés verrouillage partagé et verrouillage exclusif , également appelé verrouillage en lecture et verrouillage en écriture .

Ne discutons pas ici de la manière de l'implémenter. Décrivons le concept de verrouillage comme suit : les verrous en lecture sont partagés, ou ils ne se bloquent pas. Plusieurs clients peuvent lire la même ressource en même temps sans interférer les uns avec les autres. Les verrous d'écriture sont exclusifs, ce qui signifie qu'un verrou d'écriture bloquera d'autres verrous d'écriture et de lecture. Ce n'est qu'ainsi que l'on peut garantir qu'un seul utilisateur peut effectuer des écritures à un moment donné. empêcher d'autres utilisateurs de lire la même ressource en cours d'écriture.

Dans un système de base de données réel, le verrouillage se produit à chaque instant lorsqu'un utilisateur modifie une certaine partie des données, MySQL empêchera les autres utilisateurs de lire les mêmes données via le verrouillage. La plupart du temps, la gestion interne des verrous MySQL est transparente.

Granarité du verrouillage

Une façon d'assurer la concurrence sur les ressources partagées consiste à rendre le verrouillage des objets plus sélectif. Essayez de verrouiller uniquement une partie des données qui doivent être modifiées, plutôt que toutes les ressources. Une approche plus idéale consiste à verrouiller précisément uniquement les éléments de données qui seront modifiés (en particulier, verrouiller les champs modifiés). A tout moment, sur une ressource donnée, plus la quantité de données verrouillées est faible, plus la concurrence du système est élevée, à condition qu'il n'y ait pas de conflit entre elles.

Le problème est que le verrouillage consomme également des ressources. Diverses opérations de verrouillage, notamment l'acquisition du verrou, la vérification si le verrou a été libéré, la libération du verrou, etc., augmenteront la surcharge du système. Si le système passe beaucoup de temps à gérer les verrous au lieu d'accéder aux données, les performances du système peuvent en souffrir.

La stratégie dite de verrouillage consiste à rechercher un équilibre entre la surcharge de verrouillage et la sécurité des données. Cet équilibre affectera bien sûr les performances. La plupart des systèmes de bases de données commerciales n'offrent pas plus d'options et imposent généralement des verrous au niveau des lignes. la table et les implémente de diverses manières complexes pour fournir de meilleures performances autant que possible lorsqu'il y a de nombreux verrous.

MySQL offre une variété d'options, et chaque moteur de stockage MySQL peut implémenter sa propre stratégie de verrouillage et sa propre granularité de verrouillage. La gestion des verrous est une décision très importante dans la conception d’un moteur de stockage. Fixer la granularité du verrouillage à un certain niveau peut offrir de meilleures performances pour certains scénarios d'application. Mais les collègues perdront une bonne prise en charge pour d’autres scénarios d’application. Heureusement, MySQL prend en charge plusieurs architectures de moteur de stockage, il n'est donc pas nécessaire d'avoir une solution universelle unique. Les deux stratégies de verrouillage les plus importantes sont présentées ci-dessous.

Verrouillage de table (verrouillage de table)

Le verrouillage de table est la stratégie de verrouillage la plus basique dans MySQL et la stratégie avec le moins de surcharge . Le verrouillage de la table est très similaire au mécanisme de verrouillage de la boîte aux lettres décrit précédemment : il verrouille la table entière. Avant qu'un utilisateur puisse effectuer des opérations d'écriture (insertion, suppression, mise à jour, etc.) sur la table, il doit obtenir un verrou en écriture. Cela bloquera toutes les opérations de lecture et d'écriture sur la table par d'autres utilisateurs. Ce n'est que lorsqu'il n'y a pas de verrou en écriture que les autres utilisateurs en lecture peuvent obtenir le verrou en lecture, et les verrous en lecture ne se bloquent pas les uns les autres.

Les verrous de table peuvent également avoir de bonnes performances dans certains scénarios. Par exemple, les verrous de table locaux en lecture prennent en charge certains types d’opérations d’écriture simultanées. De plus, les verrous en écriture ont également une priorité plus élevée que les verrous en lecture, de sorte qu'une demande de verrou en écriture peut être insérée devant la file d'attente des verrous en lecture (un verrou en écriture peut être inséré devant un verrou en lecture dans la file d'attente des verrous, alors qu'un verrou en lecture le verrou ne peut pas être inséré) devant le verrou en écriture).

Bien que le moteur de stockage puisse gérer ses propres verrous, Mysql lui-même utilise toujours une variété de verrous de table efficaces pour atteindre différents objectifs. Par exemple, le serveur utilise des verrous de table pour des instructions telles que alter table, ignorant le mécanisme de verrouillage du moteur de stockage.

[Remarque : le mécanisme de verrouillage est géré par le moteur de stockage, mais MySQL lui-même gérera parfois de force ce mécanisme de verrouillage]

Verrouillage de ligne (verrouillage de ligne)

Les verrous au niveau des lignes peuvent prendre en charge le traitement simultané dans la plus grande mesure (mais entraînent également la plus grande surcharge de verrouillage) . Il est bien connu que le verrouillage au niveau des lignes est implémenté dans InnoDB et XtraDB, ainsi que dans certains autres moteurs de stockage. Les verrous au niveau des lignes ne sont implémentés qu'au niveau de la couche moteur de stockage , et la couche serveur MySQL (si nécessaire, veuillez consulter le schéma d'architecture logique dans l'article précédent) n'est pas implémentée. La couche serveur n'a aucune connaissance de l'implémentation du verrouillage dans le moteur de stockage. Au fur et à mesure que nous poursuivons dans ce chapitre et tout au long du livre, tous les moteurs de stockage présentent des mécanismes de verrouillage à leur manière.

Ce qui précède est le contenu du contrôle de concurrence [MySQL] Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !