Je ne comprends toujours pas la cohérence des données entre Redis et MySQL dans l'interview, il suffit de lire cet article

1. Qu'est-ce que la cohérence de la base de données et du cache

La cohérence des données fait référence à :

Il y a des données dans le cache et la valeur des données mises en cache = la valeur dans la base de données ;
Les données ne sont pas dans le cache, la valeur dans la base de données = dernière valeur.

Le reverse push cache est incohérent avec la base de données :

La valeur des données en cache ≠ la valeur dans la base de données ;
Il y a d'anciennes données dans le cache ou la base de données, ce qui oblige le thread à lire les anciennes données.

❝
Pourquoi les problèmes de cohérence des données surviennent-ils ?

Lorsque vous utilisez Redis comme cache, lorsque les données changent, nous devons effectuer une double écriture pour nous assurer que le cache est cohérent avec les données de la base de données.

La base de données et le cache, après tout, sont deux systèmes. Si vous voulez assurer une cohérence forte, vous devez introduire 2PC ou Paxos attendre des protocoles de cohérence distribuée, ou des verrous distribués, etc. Ceci est difficile à mettre en œuvre et affectera certainement les performances. Influence.

Si les exigences de cohérence des données sont vraiment si élevées, est-il vraiment nécessaire d'introduire la mise en cache ?

2. Stratégie d'utilisation du cache

Lors de l'utilisation du cache, il existe généralement les stratégies d'utilisation du cache suivantes pour améliorer les performances du système :

Cache-Aside Pattern(cache de contournement, couramment utilisé dans les systèmes d'entreprise)
Read-Through Pattern
Write-Through Pattern
Write-Behind Pattern

2.1 Cache-Aside (cache de contournement)

La soi-disant « mise en cache de contournement » signifie que les opérations de lecture du cache, de lecture de la base de données et de mise à jour du cache sont toutes effectuées dans le système d'application , qui est la stratégie de mise en cache la plus couramment utilisée pour les systèmes d'entreprise .

2.1.1 Lire les données

La logique de lecture des données est la suivante :

Lorsque l'application doit lire des données à partir de la base de données, elle vérifie d'abord si les données du cache correspondent.
Si le cache manque, interrogez la base de données pour obtenir les données et écrivez les données dans le cache en même temps, de sorte que les lectures ultérieures des mêmes données atteignent le cache et renvoient finalement les données à l'appelant.
Si le cache arrive, revenez directement.

Le chronogramme est le suivant :

Diagramme de temps de lecture du cache de contournement

avantage

Seules les données réellement demandées par l'application sont incluses dans le cache, ce qui permet de conserver une taille de cache rentable.
Il est simple à mettre en œuvre et permet d'améliorer les performances.

Le pseudocode de l'implémentation est le suivant :

String cacheKey = "公众号：码哥字节";
String cacheValue = redisCache.get(cacheKey)；
//缓存命中
if (cacheValue != null) {
  return cacheValue;
} else {
  //缓存缺失, 从数据库获取数据
  cacheValue = getDataFromDB();
  // 将数据写到缓存中
  redisCache.put(cacheValue)
}

défaut

Étant donné que les données ne sont chargées dans le cache qu'après un échec du cache, il y a une surcharge du temps de réponse de la demande de données pour l'appel initial en raison de la population de cache supplémentaire et du temps de requête de base de données requis.

2.1.2 Mettre à jour les données

Lorsque vous utilisez cache-aside le mode pour écrire des données, le flux est le suivant.

Contourner les données d'écriture du cache

écrire des données dans la base de données ;
Invalider les données dans le cache ou mettre à jour les données mises en cache ;

Lorsqu'elle est utilisée cache-aside , la stratégie d'écriture la plus courante consiste à écrire des données directement dans la base de données, mais le cache peut devenir incohérent avec la base de données.

Nous devrions définir un délai d'expiration pour le cache, ce qui est une solution pour assurer la cohérence éventuelle.

Si le délai d'expiration est trop court, l'application interrogera constamment la base de données pour obtenir des données. De même, si le délai d'expiration est trop long et que le cache n'est pas invalidé lors de la mise à jour, les données mises en cache sont susceptibles d'être sales.

La méthode la plus courante consiste à supprimer le cache pour invalider les données mises en cache .

❝
Pourquoi ne pas mettre à jour le cache ?

problème de performances

Lorsque le coût de mise à jour du cache est élevé et que plusieurs tables doivent être accessibles pour un calcul conjoint, il est recommandé de supprimer le cache directement au lieu de mettre à jour les données du cache pour garantir la cohérence.

question de sécurité

Dans un scénario à forte simultanéité, les données trouvées dans la requête peuvent être d'anciennes valeurs. J'analyserai les détails plus tard, alors ne vous inquiétez pas.

2.2 Read-Through (lecture directe)

Lorsque le cache manque, les données sont également chargées à partir de la base de données, écrites dans le cache et renvoyées au système d'application.

Bien que read-through très similaire à cache-aside , le système d'application est chargé de récupérer les données de la base de données et de remplir le cache.cache-aside

La lecture directe, en revanche, transfère la responsabilité de la récupération de la valeur dans le magasin de données au fournisseur de cache.

Lire à travers

Read-Through met en œuvre le principe de séparation des préoccupations. Le code interagit uniquement avec le cache, et le composant de cache gère la synchronisation des données entre lui-même et la base de données.

2.3 Écriture directe synchrone à écriture immédiate

Semblable à Read-Through, lorsqu'une demande d'écriture se produit, Write-Through transfère la responsabilité de l'écriture au système de cache, et la couche d'abstraction du cache termine la mise à jour des données mises en cache et des données de la base de données .

Réécriture

Write-Through Le principal avantage est que le système d'application n'a pas besoin de prendre en compte la gestion des erreurs et la logique de nouvelle tentative, et il est transféré à la couche d'abstraction du cache pour gérer la mise en œuvre.

Avantages et inconvénients

Il est inutile d'utiliser cette stratégie directement, car cette stratégie doit d'abord écrire dans le cache, puis écrire dans la base de données, ce qui entraîne un délai supplémentaire pour l'opération d'écriture.

Lorsqu'il est utilisé Write-Through conjointement avec , il peut tirer pleinement parti de ses avantages tout en garantissant la cohérence des données sans se soucier de la manière d'invalider les paramètres de cache.Read-ThroughRead-Through

Réécriture

Cette stratégie inverse Cache-Aside l'ordre de remplissage du cache. Au lieu de retarder le chargement dans le cache après un échec du cache, les données sont d'abord écrites dans le cache, puis le composant de cache écrit les données dans la base de données .

avantage

Les données du cache et de la base de données sont toujours à jour ;
Les performances des requêtes sont optimales, car les données à interroger peuvent déjà avoir été écrites dans le cache.

défaut

Les données rarement demandées sont également écrites dans le cache, ce qui entraîne un cache plus grand et plus coûteux.

2.4 Écriture derrière

Cette image semble être la même à première vue Write-Through , mais ce n'est pas le cas. La différence est la flèche de la dernière flèche : elle passe du plein au trait.

Cela signifie que le système de cache mettra à jour les données de la base de données de manière asynchrone et que le système d'application n'interagit qu'avec le système de cache .

Les applications n'ont pas à attendre que les mises à jour de la base de données soient terminées, ce qui améliore les performances des applications car les mises à jour de la base de données sont les opérations les plus lentes.

Écriture derrière

Avec cette stratégie, la cohérence entre le cache et la base de données n'est pas forte et n'est pas recommandée pour les systèmes à haute cohérence.

3. Analyse des problèmes de cohérence sous bypass cache

La stratégie (contournement de la mise en cache) est la plus couramment utilisée dans les scénarios d'entreprise Cache-Aside . Dans le cadre de cette stratégie, le client lit d'abord les données du cache et renvoie s'il réussit ; s'il échoue, il lit à partir de la base de données et écrit les données dans le cache , ainsi les opérations de lecture n'entraîneront pas d'incohérences entre le cache et la base de données.

L'accent est mis sur les opérations d'écriture. La base de données et le cache doivent être modifiés, et il y aura une séquence entre les deux, ce qui peut entraîner la perte de cohérence des données . Pour écrire, nous devons considérer deux questions :

Mettre d'abord à jour le cache ou mettre à jour la base de données ?
Lorsque les données changent, choisir de modifier le cache (mise à jour) ou de supprimer le cache (supprimer) ?

En combinant ces deux questions, quatre solutions émergent :

Mettez d'abord à jour le cache, puis mettez à jour la base de données ;
Mettez d'abord à jour la base de données, puis mettez à jour le cache ;
Supprimez d'abord le cache, puis mettez à jour la base de données ;
Mettez d'abord à jour la base de données, puis supprimez le cache.

Dans l'analyse suivante, vous n'avez pas à le mémoriser par cœur, la clé est que vous n'avez qu'à considérer si les deux scénarios suivants causeront de sérieux problèmes pendant le processus de déduction :

Si la première opération réussit et la seconde échoue, qu'est-ce qui causerait le problème ?
Cela entraînera-t-il des incohérences dans la lecture des données en cas de forte simultanéité ?

❝
Pourquoi ne pas envisager le premier échec et le second succès ?

tu devines?

Étant donné que le premier échoue, il n'est pas nécessaire d'exécuter le second, renvoyez simplement 50x et d'autres informations anormales dans la première étape, et il n'y aura pas d'incohérence.

Ce n'est que lorsque le premier réussit que le second échec est un casse-tête.Pour assurer leur atomicité, il implique le périmètre des transactions distribuées.

3.1 Mettez d'abord à jour le cache, puis mettez à jour la base de données

Mettez d'abord à jour le cache, puis mettez à jour la base de données

Si la mise à jour du cache réussit en premier, mais que l'écriture dans la base de données échoue, le cache contiendra les dernières données et la base de données contiendra les anciennes données, alors le cache sera des données sales.

Après cela, lorsque d'autres requêtes arrivent immédiatement, ces données seront obtenues, mais ces données n'existent pas dans la base de données.

Pour les données qui n'existent pas dans la base de données, il est inutile de les mettre en cache et de les renvoyer au client.

Le programme est simple Pass.

3.2 Mettez d'abord à jour la base de données, puis mettez à jour le cache

Tout fonctionne comme suit :

Écrivez d'abord la base de données, succès ;
Ensuite, mettez à jour le cache, succès.

Échec de la mise à jour du cache

À ce stade, déduisons que si l'atomicité de ces deux opérations est brisée : quels problèmes en résulteront si la première étape réussit et la seconde échoue ?

Cela entraînera la base de données avec les dernières données et le cache avec les anciennes données, ce qui entraînera des problèmes de cohérence.

Je ne vais pas dessiner cette image, elle est similaire à l'image précédente, il suffit d'inverser les positions de Redis et MySQL.

Scénario de simultanéité élevée

Xie Bage souvent 996, il a mal au dos et au cou, il écrit de plus en plus de bugs, il veut aller se faire masser pour améliorer ses compétences en programmation.

Touchés par l'épidémie, la commande a du mal à passer, et les techniciens des clubs haut de gamme se bousculent pour prendre cette commande, haute concurence, frères.

Après être entré dans le magasin, la réception entrera les informations du client dans le système. set xx的服务技师 = 待定La valeur initiale de l'exécution indique qu'il n'y a actuellement aucune réception et l'enregistre dans la base de données et le cache, puis organise le service de massage du technicien.

Comme indiqué ci-dessous:

La simultanéité élevée met d'abord à jour la base de données, puis met à jour le cache

Le technicien n ° 98 a agi en premier et a écrit set 谢霸歌的服务技师 = 98 la commande envoyée au système dans la base de données.A ce moment, le réseau du système a fluctué et s'est figé, et les données n'avaient pas eu le temps d'être écrites dans le cache .
Ensuite, le technicien n ° 520 a également envoyé au système set 谢霸哥的服务技师 = 520pour écrire dans la base de données et a également écrit ces données dans le cache.
À ce moment, la demande d'écriture dans le cache du technicien n° 98 a commencé à être exécutée et les données ont été set 谢霸歌的服务技师 = 98 écrites avec succès dans le cache.

Enfin, il a été constaté que la valeur de la base de données = set 谢霸哥的服务技师 = 520, et la valeur du cache = set 谢霸歌的服务技师 = 98.

Les dernières données du technicien 520 dans le cache sont écrasées par les anciennes données du technicien 98.

Par conséquent, dans un scénario à haute simultanéité, si plusieurs threads écrivent des données en même temps, puis écrivent dans le cache, il y aura des incohérences où le cache est l'ancienne valeur et la base de données est la dernière valeur.

Le programme passe directement.

❝
Si la première étape échoue, une exception 50x sera renvoyée directement et il n'y aura pas d'incohérence des données.

3.3 Supprimer d'abord le cache, puis mettre à jour la base de données

Selon la routine mentionnée par "Brother Code", en supposant que la première opération réussisse et que la seconde échoue, que se passera-t-il ? Que se passe-t-il dans les scénarios à forte simultanéité ?

Échec de l'écriture dans la base de données à la deuxième étape

Supposons qu'il y ait maintenant deux requêtes : la requête d'écriture A et la requête de lecture B.

La première étape de la demande d'écriture A consiste à supprimer le cache avec succès, mais à ne pas écrire de données dans la base de données, ce qui entraînera la perte des données écrites, et la base de données enregistrera l'ancienne valeur .

Ensuite, une autre demande de lecture B arrive et constate que le cache n'existe pas, lit les anciennes données de la base de données et les écrit dans le cache.

Problèmes sous forte concurrence

Supprimez d'abord le cache, puis écrivez la base de données

Il est préférable que le technicien n° 98 agisse en premier. Le système reçoit une demande de suppression des données en cache. Lorsque le système est sur le point d' set 肖菜鸡的服务技师 = 98écrire dans la base de données, il se fige et il est trop tard pour écrire.
À ce moment, le responsable du lobby exécute une demande de lecture au système pour vérifier si Xiao Caiji dispose d'un accueil de technicien, afin d'organiser un service de technicien. Le système détecte qu'il n'y a pas de données dans le cache, il lit donc les anciennes données à partir de la base de données et l'écrit dans le cache set 肖菜鸡的服务技师 = 待定.
À ce moment, l'opération d'écriture des données dans la base de données par le technicien n° 98 dans le gel d'origine set 肖菜鸡的服务技师 = 98est terminée.

De cette manière, les anciennes données seront mises en cache et les dernières données ne pourront pas être lues avant l'expiration du cache. Xiao Caiji avait déjà été accepté par le technicien n°98, mais le responsable du hall pensait qu'il n'y avait personne.

Ce schéma réussit, car la première étape réussit et la deuxième échoue, la base de données contiendra d'anciennes données et il n'y aura pas de données dans le cache. Continuez à lire les anciennes valeurs de la base de données et écrivez-les dans le cache, entraînant une incohérence des données, et un cache de plus.

Qu'il s'agisse d'une situation anormale ou d'un scénario à forte simultanéité, cela entraînera une incohérence des données. manquer.

3.4 Mettez d'abord à jour la base de données, puis supprimez le cache

Après avoir adopté les trois plans précédents, ils ont tous été adoptés. Analysons si le plan final fonctionnera ou non.

Selon la "routine", jugez respectivement quels problèmes seront causés par une anomalie et une forte simultanéité.

Cette stratégie permet de savoir que si la phase d'écriture dans la base de données échoue, une exception sera renvoyée au client, et il n'est pas nécessaire d'effectuer des opérations de mise en cache.

Par conséquent, si la première étape échoue, il n'y aura pas d'incohérence des données.

Impossible de supprimer le cache

Le fait est que la première étape consiste à écrire avec succès les dernières données dans la base de données, mais que dois-je faire si le cache ne parvient pas à être supprimé ?

Vous pouvez placer ces deux opérations dans une seule transaction et, lorsque la suppression du cache échoue, annuler l'écriture dans la base de données.

❝
Il n'est pas adapté aux scénarios à forte simultanéité et les transactions volumineuses sont susceptibles de se produire, provoquant des problèmes de blocage.

Si vous n'effectuez pas de restauration, il apparaîtra que la base de données contient de nouvelles données, que le cache contient toujours d'anciennes données et que les données sont incohérentes. Que dois-je faire ?

Par conséquent, nous devons trouver un moyen de réussir la suppression du cache, sinon nous ne pouvons qu'attendre que la période de validité expire.

Utilisez un mécanisme de nouvelle tentative.

Par exemple, réessayez trois fois, si cela échoue trois fois, enregistrez le journal dans la base de données et utilisez le composant de planification distribuée xxl-job pour implémenter le traitement suivant.

Dans les scénarios à forte simultanéité, il est préférable d'utiliser des méthodes asynchrones pour réessayer , telles que l'envoi de messages au middleware mq pour obtenir un découplage asynchrone.

Ou utilisez le framework Canal pour vous abonner au journal binlog MySQL, surveiller la demande de mise à jour correspondante et supprimer l'opération de cache correspondante.

Scénario de simultanéité élevée

Analysons les problèmes de lecture et d'écriture simultanées élevées...

Écrivez d'abord dans la base de données, puis supprimez le cache

Le technicien n ° 98 a agi en premier et a repris l'entreprise de Xiao Caiji, set 肖菜鸡的服务技师 = 98et la base de données l'a exécutée, le réseau était toujours bloqué et il n'a pas eu le temps d'exécuter l'opération de suppression du cache .
Candy, le superviseur, exécute une requête de lecture au système, vérifie si Xiao Caiji est reçu par un technicien, constate qu'il y a des données dans le cache, 肖菜鸡的服务技师 = 待定et renvoie directement l'information au client. Le superviseur pense qu'il n'y a pas un pour le recevoir.
À l'origine, le technicien n ° 98 a pris la commande, mais le cache n'a pas été supprimé en raison du gel, et maintenant la suppression est réussie.

Une petite quantité d'anciennes données peut être lue dans une requête de lecture, mais les anciennes données seront bientôt supprimées, et les requêtes suivantes peuvent obtenir les dernières données, ce qui n'est pas un gros problème.

Il existe également une situation plus extrême. Lorsque le cache est automatiquement invalidé, il rencontre une situation de lecture et d'écriture simultanées élevées. Supposons qu'il y ait deux demandes, un thread A effectue l'opération de requête et l'autre thread B effectue l'opération de mise à jour, puis il y aura la situation suivante produire:

invalidation du cache

Le délai d'expiration du cache expire et le cache devient invalide.
Le thread A lit la demande de lecture du cache et rate, puis interroge la base de données pour obtenir une ancienne valeur (car B écrira une nouvelle valeur, relativement parlant, c'est une ancienne valeur), et lorsque les données sont écrites dans le cache, le problème de réseau d'envoi est bloqué .
Le thread B effectue une opération d'écriture, écrivant la nouvelle valeur dans la base de données.
Le thread B exécute la suppression du cache.
Le thread A continue, se réveille du gel et écrit l'ancienne valeur interrogée dans le cache.

❝
Code frère, comment jouer à ça, il y a encore une incohérence.

Ne paniquez pas, la probabilité que cela se produise est très faible. Les conditions nécessaires pour que la situation ci-dessus se produise sont :

L'opération d'écriture dans la base de données à l'étape (3) prend moins de temps et est plus rapide que l'opération de lecture à l'étape (2), de sorte que l'étape (4) peut précéder l'étape (5).
Le cache vient d'atteindre sa date d'expiration.

Habituellement, le QPS de MySQL autonome est d'environ 5K et le TPS est d'environ 1k (ps: le QPS de Tomcat est d'environ 4K, TPS = environ 1k).

Les opérations de lecture de la base de données sont beaucoup plus rapides que les opérations d'écriture (c'est justement à cause de cela que se fait la séparation lecture-écriture), il est donc difficile que l'étape (3) soit plus rapide que l'étape (2), et il faut aussi coopérer avec l'échec du cache.

Par conséquent, lors de l'utilisation de la stratégie de contournement du cache, il est recommandé de l'utiliser pour les opérations d'écriture : mettez d'abord à jour la base de données, puis supprimez le cache.

4. Quelles sont les solutions de cohérence ?

Enfin, pour la stratégie Cache-Aside (cache de contournement), lorsque l'opération d'écriture est utilisée pour mettre à jour la base de données d'abord, puis supprimer le cache, analysons quelles sont les solutions de cohérence des données ?

4.1 Double suppression du délai de cache

Comment éviter les données sales si vous supprimez d'abord le cache puis mettez à jour la base de données ?

❝
Une stratégie de double suppression différée est adoptée.

Supprimez d'abord le cache.
Ecrire dans la base de données.
Veille pendant 500 millisecondes avant de supprimer le cache.

De cette façon, il n'y aura qu'un temps de lecture des données sales pouvant aller jusqu'à 500 millisecondes. La clé est de savoir comment déterminer le temps de sommeil?

Le but du temps de retard est de garantir que la demande de lecture se termine et que la demande d'écriture peut supprimer les données modifiées du cache causées par la demande de lecture.

Par conséquent, nous devons évaluer nous-mêmes la consommation de temps de la logique métier de lecture des données du projet et ajouter quelques centaines de millisecondes comme temps de retard sur la base de la consommation de temps de lecture .

4.2 Mécanisme de nouvelle tentative de suppression du cache

❝
Que dois-je faire si la suppression du cache échoue ? Par exemple, si la deuxième suppression de la double suppression retardée échoue, cela signifie que les données modifiées ne peuvent pas être supprimées.

Utilisez le mécanisme de nouvelle tentative pour vous assurer que le cache est supprimé avec succès.

Par exemple, réessayez trois fois, si cela échoue trois fois, le journal sera enregistré dans la base de données et un avertissement sera envoyé pour une intervention manuelle.

mécanisme de nouvelle tentative

Étape (5) Si la suppression échoue et que le nombre maximal de tentatives n'a pas été atteint, le message sera remis en file d'attente jusqu'à ce que la suppression soit réussie, sinon il sera enregistré dans la base de données et interviendra manuellement.

Cette solution a un inconvénient, qui est l'intrusion dans le code métier, il y a donc la solution suivante, qui consiste à démarrer un service qui s'abonne spécifiquement à la base de données binlog pour lire les données qui doivent être supprimées et effectuer l'opération de suppression du cache .

4.3 Lire binlog et supprimer de manière asynchrone

Binlog supprime de manière asynchrone

mettre à jour la base de données ;
La base de données enregistrera les informations d'opération dans le journal binlog ;
Utilisez canal pour vous abonner aux journaux binlog afin d'obtenir les données et les clés cibles ;
Le système de suppression de cache obtient les données du canal, analyse la clé cible et essaie de supprimer le cache.
Si la suppression échoue, le message est envoyé dans la file d'attente des messages ;
Le système de suppression de cache récupère les données de la file d'attente de messages et exécute à nouveau l'opération de suppression.

Résumer

La meilleure pratique pour la stratégie de mise en cache est Cache Aside Pattern. Elles sont divisées en meilleures pratiques de mise en cache en lecture et en meilleures pratiques de mise en cache en écriture.

La meilleure pratique du cache de lecture : lisez d'abord le cache, retournez s'il y a succès ; interrogez la base de données si elle échoue, puis écrivez dans le cache.

Rédigez les meilleures pratiques de mise en cache :

Écrivez d'abord dans la base de données, puis exploitez le cache ;
Supprimez directement le cache au lieu de le modifier, car lorsque le coût de mise à jour du cache est très élevé et que vous devez accéder à plusieurs tables pour un calcul conjoint, il est recommandé de supprimer directement le cache au lieu de le mettre à jour. la suppression du cache est simple, et l'effet secondaire est seulement d'augmenter un chache raté. Il est recommandé que tout le monde utilise cette stratégie.

Dans le cadre des meilleures pratiques ci-dessus, afin d'assurer au maximum la cohérence du cache et de la base de données, nous pouvons utiliser la double suppression différée.

Pour éviter l'échec de la suppression, nous utilisons un mécanisme de nouvelle tentative asynchrone pour garantir une suppression correcte. Avec le mécanisme asynchrone, nous pouvons envoyer un message de suppression au middleware de message mq, ou utiliser canal pour s'abonner au journal binlog MySQL pour écouter les demandes d'écriture et supprimer le cache correspondant.

Alors, que se passe-t-il si je dois assurer une cohérence absolue, laissez-moi d'abord donner une conclusion :

Il n'y a aucun moyen d'obtenir une cohérence absolue, qui est déterminée par la théorie CAP.Le scénario dans lequel le système de cache est applicable est le scénario de cohérence non forte, il appartient donc à l'AP dans CAP.

Par conséquent, nous devons faire des compromis et nous pouvons atteindre la cohérence finale mentionnée dans la théorie BASE .

En fait, une fois que le cache est utilisé dans la solution, cela signifie souvent que nous renonçons à la forte cohérence des données, mais cela signifie également que notre système peut obtenir une amélioration des performances.

Le soi-disant compromis est exactement cela.

Si vous pensez que cet article vous est utile, veuillez l'aimer et le suivre pour le soutenir. Si vous voulez en savoir plus sur le backend Java, le big data et les dernières informations dans le domaine des algorithmes, vous pouvez suivre mon compte public [Architecte Lao Bi] message privé 666 pour obtenir plus de Java post Terminal, Big Data, Algorithm PDF + Dachang dernières questions d'entretien tri + conférence vidéo