Étant donné que le fonctionnement des données MySQL est également effectué dans la couche métier, il est naturel de synchroniser d'autres sources de données dans la couche métier. Une approche plus courante consiste à écrire une synchronisation pertinente dans le hook hook de l'ORM. code.
L'inconvénient de cette approche est que lorsqu'il y a de plus en plus de services, les parties synchronisées peuvent être trop dispersées, ce qui rend difficile la mise à jour et l'itération. Par exemple, une migration incompatible des index ES peut affecter l'ensemble du système.
Lorsque l'architecture de l'application évolue vers des microservices, chaque service ne peut plus appeler directement MySQL, mais via une couche de middleware. À ce stade, le middleware peut faire fonctionner MySQL tout en synchronisant d'autres sources de données.
Cette méthode nécessite une adaptation du middleware et présente une certaine complexité.
Définissez des champs spéciaux dans la structure de la table MySQL, tels que update_at (heure de mise à jour des données). Sur la base de ce champ, les tâches planifiées interrogent les données réellement modifiées, réalisant ainsi les données. update Mises à jour incrémentielles.
Vous pouvez utiliser le Logstash open source pour compléter cette méthode.
Bien sûr, l'inconvénient est également évident, c'est-à-dire que la suppression des données ne peut pas être synchronisée.
Par exemple, le célèbre canal.
Déguisez-vous en esclave pour analyser le journal binaire de MySQL et en savoir plus sur les modifications de données.
Il s'agit d'une solution relativement mature dans l'industrie.
Cette méthode nécessite que vous définissiez le binlog-format
de MySQL en mode ROW
. binlog-format
设置为 ROW
模式。
MySQL 的 binlog
有三种格式:
ROW
模式,binlog 按行的方式去记录数据的变更;
statement
模式,binlog 记录的是 SQL 语句;
mixed
模式时,混合以上两种,记录的可能是 SQL 语句或者 ROW
模式的每行变更;
某些情况下,可能你的 MySQL binlog
无法被设置为 ROW
模式,这种时候,我们仍然可以去统一解析 binlog ,从而完成同步,但是这里解析出来的当然还是原始的 SQL 语句或者 ROW
Le binlog
de MySQL a trois formats :
ROW
, binlog enregistre les modifications de données dans les lignes ; 🎜
instruction
, binlog enregistre C'est une instruction SQL ; 🎜
En mode mixte
, les deux ci-dessus sont mélangés, et ce qui est enregistré peut être une instruction SQL ou chaque ligne en mode ROW
. Change ; 🎜
binlog
MySQL peut ne pas être défini en mode ROW
. Dans ce cas, nous pouvons toujours le faire. analyser uniformément le binlog pour terminer la synchronisation, mais ce qui est analysé ici est bien sûr l'instruction SQL d'origine ou chaque changement de ligne du modèle ROW
. À ce stade, nous devons analyser ces SQL ou chaque ligne en fonction. aux changements commerciaux, tels que l'utilisation d'une correspondance régulière ou d'un arbre de syntaxe abstraite AST, etc., puis la synchronisation des données en fonction des résultats de l'analyse. 🎜🎜Les limites de cette méthode sont également évidentes. Premièrement, vous devez adapter votre analyse métier SQL. Deuxièmement, les scénarios de mise à jour par lots peuvent être difficiles à gérer. Bien sûr, si vos données sont simplement modifiées ou supprimées en fonction de la clé primaire, vous pouvez mieux l'appliquer. 🎜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!