Contexte

Il y a une phrase très célèbre dans "Westward Journey" de Xingye : "Il était une fois un amour sincère que je faisais Je ne chérissais pas la relation avant moi et je l'ai regretté quand je l'ai perdue. La chose la plus douloureuse au monde est la suivante. Si Dieu pouvait me donner une autre chance, je dirais trois mots à n'importe quelle fille : « Je t'aime. Je dois ajouter une limite de temps à cet amour, j'espère que ce sera dix mille ans ! " Aux yeux de nos développeurs, ce sentiment est le même que les données de notre base de données. Comme nous souhaitons qu'il dure dix mille ans ! Non changeant, mais se retourne souvent contre nous. À mesure que l'entreprise continue de se développer et que l'activité continue d'évoluer, nos besoins en données changent également constamment. Il existe probablement les situations suivantes :

Sous-base de données et. sous-tableau : Le développement commercial devient de plus en plus rapide, ce qui entraîne une pression croissante sur les bases de données mono-machine, et la quantité de données augmente également. À l'heure actuelle, la méthode des sous-bases de données est généralement utilisée pour résoudre ce problème. problème, et la base de données est Le trafic est réparti uniformément sur différentes machines. Dans le processus passant d'une base de données autonome à une sous-base de données, nous devons migrer complètement nos données afin de pouvoir utiliser avec succès nos données dans une sous-base de données.
Remplacer le support de stockage : De manière générale, après avoir migré la sous-base de données décrite ci-dessus, le support de stockage sera toujours le même. Par exemple, nous utilisions auparavant un Mysql autonome. . Après la sous-base de données, c'est devenu MySQL sur plusieurs machines, et les champs des tables de notre base de données n'ont pas changé. La migration est relativement simple. Parfois, nos sous-bases de données et nos tables ne peuvent pas résoudre tous les problèmes. Si nous avons besoin de beaucoup de requêtes complexes, l'utilisation de Mysql n'est peut-être pas une solution fiable pour le moment. Nous devons alors remplacer le support de stockage des requêtes, par exemple en utilisant elasticsearch This This. Ce type de migration est légèrement plus compliqué et implique la conversion de données à partir de différents supports de stockage.
Passer à un nouveau système : Généralement, lorsqu'une entreprise se développe à un rythme rapide, de nombreux projets seront construits à plusieurs reprises dans un souci de rapidité. Pendant une certaine période, ces projets seront souvent fusionnés et deviendront une plateforme ou une plateforme intermédiaire, comme certains de nos systèmes d'adhésion, nos systèmes de commerce électronique, etc. À l'heure actuelle, nous sommes souvent confrontés à un problème : les données de l'ancien système doivent être migrées vers le nouveau système. Cette fois-ci, il est possible que non seulement le support de stockage ait changé, mais également la langue du projet. être différent.Du niveau supérieur D'un point de vue différent, les départements peuvent être différents, ce type de migration de données est donc plus difficile et le risque est plus grand.

Dans le développement commercial réel, nous élaborerons différents plans de migration en fonction de différentes situations. Discutons ensuite de la manière de migrer les données.

Migration des données

La migration des données ne se fait pas du jour au lendemain. Chaque migration de données prend beaucoup de temps, cela peut prendre une semaine, cela peut prendre plusieurs mois. De manière générale, nous migrons les données. est fondamentalement similaire à l'image ci-dessous : ' Tout d'abord, nous devons migrer par lots les données existantes dans notre base de données, puis nous devons traiter les nouvelles données. Nous devons écrire cette partie des données dans notre nouveau stockage en temps réel après avoir écrit la base de données d'origine. vérifier en permanence les données pendant le processus. Lorsque nous vérifions que les problèmes de base ne sont pas graves, nous effectuerons alors l’opération de coupure de flux. Une fois la coupure de flux terminée, nous n’aurons plus besoin d’effectuer de vérification des données ni de migration incrémentielle des données.

Migration de données existantes

Tout d'abord, parlons de la façon de migrer des données existantes. Après avoir effectué des recherches dans la communauté open source, nous avons constaté qu'il n'existait pas d'outil facile à utiliser. Migration de données existantes.À l'heure actuelle, le DTS du cloud d'Alibaba fournit la migration de données existantes. DTS prend en charge la migration entre des sources de données homogènes et hétérogènes et prend essentiellement en charge les bases de données courantes de l'industrie telles que Mysql, Orcale, SQL Server, etc. DTS est plus adapté aux deux premiers scénarios que nous avons mentionnés précédemment. L'un est le scénario de sous-base de données. Si vous utilisez le DRDS d'Alibaba Cloud, vous pouvez directement migrer les données vers DRDS via DTS. qu'il s'agisse de Redis, ES et DTS, tous prennent en charge la migration directe.

Alors comment migrer le stock DTS ? En fait, c'est relativement simple et comprend probablement les étapes suivantes :

Lorsque la tâche de migration du stock est lancée, nous obtenons le plus grand identifiant et le plus petit identifiant qui doivent actuellement être migrés
Définissez un segment, par exemple 10 000, interrogez 10 000 données à chaque fois en commençant par le plus petit identifiant et envoyez-le au serveur DTS pour traitement. Le sql est le suivant :

select * from table_name where id > curId and id < curId + 10000;复制代码

Copier après la connexion

3 Lorsque l'id est supérieur ou égal à maxId, la tâche de migration de données existante se termine

Bien sûr, nous ne pouvons pas utiliser Alibaba Cloud dans le processus de migration réel, ou dans notre troisième scénario, nous devons faire beaucoup de conversions entre les champs de base de données, et DTS ne le prend pas en charge, alors nous pouvons imiter l'approche de DTS est de migrez les données en lisant les données par lots dans les segments. Ce qu'il faut noter ici, c'est que lorsque nous migrons des données par lots, nous devons contrôler la taille et la fréquence des segments pour éviter qu'ils n'affectent le fonctionnement normal de nos opérations en ligne.

Migration incrémentale des données

Les solutions de migration des données existantes sont relativement limitées, mais les méthodes de migration incrémentielle des données sont en plein essor. De manière générale, nous disposons des méthodes suivantes :

DTS : le DTS d'Alibaba Cloud est un service à guichet unique. Il fournit non seulement une migration de données boursières, mais également une migration de données incrémentielle, mais il doit être facturé en fonction du volume.
Service double écriture : plus adapté à la migration sans changement de système, c'est-à-dire que seul le stockage est modifié mais le système est toujours le même, comme la sous-base de données et la table, la synchronisation des données Redis, etc. La méthode est relativement simple et directe. Les données à migrer sont écrites de manière synchrone dans le code, mais comme il ne s'agit pas de la même base de données, les transactions ne peuvent pas être garanties, ce qui peut entraîner une perte de données lors de la migration des données. vérification ultérieure des données.
Écriture asynchrone MQ : cela peut être appliqué à tous les scénarios. Lorsque les données sont modifiées, un message MQ est envoyé et le consommateur met à jour les données après avoir reçu le message. Ceci est quelque peu similaire à la double écriture ci-dessus, mais cela change le fonctionnement de la base de données en MQ asynchrone, et la probabilité de problèmes sera beaucoup plus faible
Surveillance du binlog : nous pouvons utiliser le canal mentionné précédemment ou d'autres Open source tels que car databus effectue la surveillance du binlog. La méthode de surveillance du binlog est la même que la méthode de message MQ ci-dessus, sauf que l'étape d'envoi des messages a été omise. Le développement de cette méthode est fondamentalement minime.

Avec autant de méthodes, laquelle devrions-nous utiliser ? Personnellement, je recommande la méthode de surveillance du binlog. La surveillance du binlog réduit les coûts de développement. Il suffit d'implémenter la logique du consommateur, et les données peuvent garantir la cohérence. Puisqu'il s'agit d'un binlog surveillé, il n'y a pas lieu de s'inquiéter de la double écriture précédente. étant différents.

Vérification des données

Toutes les solutions mentionnées ci-dessus, bien que beaucoup d'entre elles soient des services cloud matures (dts) ou des middlewares (canal), peuvent entraîner certaines pertes de données. La perte de données est généralement relativement rare, mais il est très difficile de dépanner. Il se peut que le dts ou le canal ait accidentellement tremblé, ou que les données aient été accidentellement perdues lors de la réception des données. Puisque nous n'avons aucun moyen d'empêcher la perte de nos données pendant le processus de migration, nous devons les corriger par d'autres moyens.

De manière générale, lorsque nous migrerons des données, il y aura une étape de vérification des données, mais différentes équipes peuvent choisir différentes solutions de vérification des données :

Avant, à Meituan Quand, nous le ferons faites une double lecture, c'est-à-dire que toutes nos lectures liront une copie de la nouvelle, mais celle renvoyée est toujours l'ancienne. À ce stade, nous devons vérifier cette partie des données. nous pouvons l'envoyer une alarme pour une réparation manuelle ou une réparation automatique. De cette façon, nos données couramment utilisées peuvent être rapidement réparées. Bien sûr, nous effectuerons également une vérification complète des données de temps en temps, mais le temps nécessaire à ce type de vérification pour réparer les données est relativement long.
Maintenant, après Yuanfudao, nous n'avons pas adopté la méthode précédente, car bien que la vérification par double lecture puisse rapidement trouver des erreurs dans les données, nous n'avons pas un niveau aussi élevé de correction en temps réel de cette partie du La quantité de développement de code pour la vérification et la double lecture est encore relativement importante, mais elle ne peut pas être garantie par des contrôles complets de temps en temps, ce qui entraînera un temps de vérification extrêmement prolongé de nos données. Nous avons adopté une méthode de compromis. Nous avons emprunté une idée du T+1 en réconciliation. Nous avons obtenu les données mises à jour d'hier dans l'ancienne base de données tous les matins, puis les avons comparées une à une avec les données de notre nouvelle base de données. est différent ou manquant, nous pouvons le réparer immédiatement.

Bien sûr, nous devons également prêter attention aux points suivants pendant le processus de développement proprement dit :

Comment garantir l'exactitude de la tâche de vérification des données ? La tâche de vérification consiste à l'origine à corriger d'autres données, mais si elle a des problèmes avec elle-même, elle perd le sens de la vérification. Actuellement, c'est le seul moyen de le faire. consiste à corriger d'autres données. S'appuyer sur la révision du code pour garantir l'exactitude de la tâche de vérification.
Lors de la vérification de la tâche, vous devez faire attention à l'impression des journaux. Parfois, des problèmes peuvent être causés par des problèmes directs avec toutes les données. La tâche de vérification peut alors imprimer un grand nombre de journaux d'erreurs, puis déclencher une alarme. , ce qui peut bloquer le système ou affecter les services d'autres personnes. Si vous souhaitez simplifier les choses ici, vous pouvez transformer certaines alarmes non traitées manuellement en avertissements. Si vous souhaitez rendre les choses plus compliquées, vous pouvez encapsuler un outil lorsqu'une certaine erreur est imprimée lorsqu'elle dépasse un certain montant dans un. pendant un certain temps, il n'est pas nécessaire de l'imprimer à nouveau.
Veillez à ne pas affecter les services en cours d'exécution en ligne de la tâche de vérification. Habituellement, la tâche de vérification écrira de nombreuses instructions de requête par lots, ce qui peut entraîner une analyse de la table par lots. peut facilement provoquer le blocage de la base de données.

Coupe de flux

Lorsque notre vérification des données ne comporte fondamentalement aucune erreur, cela signifie que notre programme de migration est relativement stable, alors nous pouvons utiliser nos nouvelles données directement ? Bien sûr, ce n'est pas possible. Si nous changeons tout en même temps, ce serait formidable si tout se passait bien. Mais si quelque chose ne va pas, cela affectera tous les utilisateurs.

Nous devons donc ensuite faire des niveaux de gris, c'est-à-dire couper le flux. Les dimensions des différentes coupes de flux métier seront différentes. Pour les coupes de flux de dimension utilisateur, nous utilisons généralement la méthode modulo de userId pour couper les flux. Pour les entreprises de dimension locataire ou commerçant, nous devons prendre la méthode de coupe modulo de l'identifiant du locataire. le flux. Pour cette réduction du trafic, vous devez élaborer un plan de réduction du trafic, dans quelle période, quelle quantité de trafic libérer, et lors de la réduction du trafic, vous devez choisir un moment où le trafic est relativement faible. Chaque fois que vous réduisez le trafic, vous en avez besoin. pour faire des observations détaillées des journaux, résoudre les problèmes dès que possible. Le processus de libération du trafic est un processus de lent à rapide. Par exemple, au début, nous utilisons 1% du volume pour le superposer en continu. utilisez directement 10 % ou 20 % du volume pour augmenter rapidement le volume. Parce que s'il y a un problème, il sera souvent découvert lorsque le trafic est faible. S'il n'y a pas de problème avec le faible trafic, le volume peut alors être augmenté rapidement.

Faites attention à l'ID de clé primaire

Dans le processus de migration des données, une attention particulière doit être accordée à l'ID de clé primaire Dans la solution de double écriture ci-dessus, il est également mentionné que. l'ID de clé primaire doit être écrit deux fois manuellement pour éviter les erreurs de séquence de génération d'ID.

Si nous migrons en raison de sous-bases de données et de tables, nous devons considérer que notre futur ID de clé primaire ne peut pas être un ID à incrémentation automatique, et nous devons utiliser des ID distribués. Celui le plus recommandé ici est le plus recommandé. Feuille open source de Meituan. Elle prend en charge deux modes. L'un est la tendance croissante de l'algorithme de flocon de neige, mais tous les identifiants sont de type Long, ce qui convient à certaines applications qui prennent en charge Long as id. Il existe également un mode segment de nombre, qui continuera à augmenter d'en haut en fonction d'un identifiant de base que vous définissez. Et fondamentalement, tous utilisent la génération de mémoire, et les performances sont également très rapides.

Bien sûr, nous avons toujours une situation dans laquelle nous devons migrer le système. L'identifiant de clé primaire du système précédent existe déjà dans le nouveau système, notre identifiant doit donc être mappé. Si nous savons déjà quels systèmes seront migrés à l'avenir lors de la migration du système, nous pouvons utiliser la méthode de réservation, par exemple, les données actuelles du système A sont de 100 millions à 100 millions, et les données du système B sont également de 100 millions. à 100 millions. Nous devons maintenant fusionner les deux systèmes A et B en un nouveau système, puis nous pouvons estimer légèrement le tampon, par exemple en laissant 100 à 150 millions pour le système A, afin que A n'ait pas besoin d'être cartographié, et le système B est de 150 millions à 300 millions. Ensuite, lorsque nous convertissons à l'ancien identifiant du système, nous devons soustraire 150 millions. Enfin, le nouvel identifiant de notre nouveau système passera de 300 millions. Mais que se passe-t-il s’il n’y a pas de segment réservé prévu dans le système ? Vous pouvez le faire des deux manières suivantes :

Vous devez ajouter une nouvelle table et créer un enregistrement de mappage entre l'ID de l'ancien système et l'ID du nouveau système. Cette charge de travail est encore relativement importante, car notre migration générale impliquera des dizaines ou des centaines de personnes. les tables et les enregistrements. Le coût reste très élevé.
Si l'identifiant est de type Long, nous pouvons faire bon usage du fait que long est de 64 bits. Nous pouvons formuler une règle. Les identifiants de notre nouveau système partiront d'un nombre relativement grand, tel que. supérieur à Int. À partir du comptage, la partie du petit Int peut être laissée à notre ancien système pour la migration des identifiants. Par exemple, le volume de 150 millions de données au-dessus de nous n'utilise en réalité que 28 bits, il y en a donc. 4 bits peuvent toujours être utilisés, et ces 4 bits peuvent représenter 16 systèmes à migrer. Bien entendu, s'il y a plus de systèmes à migrer dans le plan, le point de départ de l'ID du nouveau système peut être défini plus grand. Comme le montre la figure ci-dessous :

Résumé

Enfin, résumons brièvement cette routine. Il s'agit en fait de quatre étapes, une seule note : stock, incrément, vérification, coupe. Stream, faites enfin attention à l'identifiant. Quelle que soit la quantité de données, il n’y aura fondamentalement aucun problème majeur lors de la migration selon cette routine. J'espère que cet article pourra vous aider dans vos travaux ultérieurs de migration de données.