Il s'agit d'une question d'entretien. L'idée générale est que la base de données utilise une méthode maître-esclave. Si une transaction implique à la fois la lecture et l'écriture (les opérations de lecture et d'écriture sont répétées), je sais qu'il peut y avoir des problèmes avec le lecture et écriture maître-esclave de la base de données dans le même processus. (Comme l'écriture s'effectue dans la bibliothèque principale et la lecture dans la bibliothèque esclave, il est possible que les données qui viennent d'être écrites dans le même processus n'aient pas été synchronisées avec la bibliothèque esclave à temps. ), mais je ne comprends pas très bien l'accent mis sur la question de savoir si cela se produira dans une transaction. Quels nouveaux problèmes surviennent et, le cas échéant, comment sont-ils résolus ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Le même processus que vous avez mentionné, lire et écrire séparément la bibliothèque maître-esclave ne devrait pas être un problème lié aux transactions, n'est-ce pas ? Parce que la même transaction ne prend pas en charge les bases de données croisées, pour autant que je sache, il n'existe pas de "transaction maître-esclave". Peut-être qu'il y en a, mais c'est l'implémentation de certaines bibliothèques et n'a rien à voir avec la base de données. . Qu'il s'agisse ou non du même processus, le problème d'une synchronisation intempestive des données peut survenir.
Il n'y a rien de mal à ce qu'une transaction comporte à la fois des opérations de lecture et d'écriture. Pensez-y, est-il raisonnable qu'une transaction ne puisse être constituée que de toutes les opérations de lecture ou de toutes les opérations d'écriture ? Le problème est que dans ce cas, afin d'assurer la cohérence des données lors de la concurrence, vous devez utiliser des verrous, tels que des verrous pessimistes : pour garantir que les données lues par la transaction en cours ne seront pas lues par d'autres transactions, et il doit attendre que l'exécution de la transaction termine l'écriture des données avant de pouvoir déverrouiller, sinon une confusion des données se produira. Par exemple : un nombre 10, deux transactions lisent 10 en parallèle sans verrous, et ajoutent 10 avant d'écrire. À ce moment, les deux transactions écrivent 20, et nous espérons que ce devrait être 30 . Je pense que cette question d'entretien devrait vous tester sur ce point.