Le système est défectueux. Il ne reconnaît que le code mais pas les personnes.

Chers amis, écoutez mes conseils. Lorsque vous écrivez du code pour fournir des méthodes permettant aux autres d'appeler, qu'il s'agisse d'un appel système interne, d'un appel système externe ou d'un appel déclenché passivement (comme la consommation MQ, l'exécution de rappel, etc.), vous devez ajouter la vérification de condition nécessaire. Ne croyez pas certains collègues qui disent que cette condition sera certainement transmise, qu'elle aura certainement une valeur, qu'elle ne sera certainement pas vide, etc. Non, juste avant le Nouvel An chinois, j'ai été trompé et j'ai eu un accident de production, donc ma prime de fin d'année a été réduite de moitié.

J'ai décidé de me concentrer sur le code lui-même, plutôt que sur les personnes, pour garantir une disponibilité et une stabilité élevées du système. Voici quelques petites leçons qui pourraient vous aider aussi.

1. Que s'est-il passé

Mon scénario commercial est le suivant : lorsque l'entreprise A change, elle déclenchera l'envoi de messages MQ, puis l'application recevra les messages MQ, et après traitement, les données seront écrites dans Elasticsearch.

(1) Reçu une alarme anormale de l'entreprise A. L'alarme à ce moment-là était la suivante :

(2) Cela semble un peu étrange à première vue. Comment cela pourrait-il être une anomalie Redis ? Ensuite, je me suis connecté à Redis et il n'y a eu aucun problème. J'ai vérifié à nouveau le cluster Redis et tout était normal. J'ai donc laissé tomber, pensant qu'il s'agissait d'un problème de réseau accidentel.

Puis, dans le groupe problèmes techniques, le service client a signalé que certains utilisateurs rencontraient des situations anormales. J'ai immédiatement vérifié le système pour confirmer l'existence de problèmes sporadiques.

(4) J'ai donc regardé quelques composants de base par habitude :

• État de la passerelle, état de chargement des pods du cœur de métier et état de chargement des pods du centre utilisateur.
• Situation MySQL : mémoire, CPU, SQL lent, blocage, nombre de connexions, etc.

Nous avons constaté une situation de SQL lent et de temps de verrouillage des métadonnées long, principalement en raison de la grande quantité de données et de la vitesse d'exécution lente causée par la requête de table complète d'une grande table, ce qui a conduit à un verrouillage des métadonnées trop long, donc épuisant le numéro de connexion à la base de données.

SELECT xxx,xxx,xxx,xxx FROM 一张大表

(6) Après avoir immédiatement supprimé plusieurs sessions lentes, j'ai constaté que le système n'avait toujours pas complètement récupéré. Pourquoi ? Maintenant que la base de données est normale, pourquoi n’a-t-elle pas été entièrement restaurée ? J'ai continué à examiner la surveillance des applications et j'ai découvert que 2 des 10 pods du centre utilisateur étaient anormaux et que le processeur et la mémoire étaient épuisés. Pas étonnant qu'il y ait des anomalies occasionnelles lors de son utilisation. J'ai donc rapidement redémarré le Pod et restauré d'abord l'application.

(7) Le problème a été détecté. Ensuite, nous continuerons à rechercher pourquoi le Pod dans le centre utilisateur raccroche. Commencez à analyser à partir des points de doute suivants :

• Y a-t-il un problème avec le code de synchronisation des données avec Elasticsearch ? Pourquoi ne peut-il pas se connecter à Redis ?
• Pourrait-il y avoir trop d'exceptions, ce qui entraînerait une saturation de la file d'attente du pool de threads pour l'envoi des messages d'avertissement d'exception, puis du MOO ?
• Où puis-je effectuer une requête de table complète inconditionnelle sur la grande table de l'entreprise A ?

(8) Continuer à enquêter sur le point de suspicion a. Au début, je pensais que le lien Redis ne pouvait pas être obtenu, ce qui a provoqué l'entrée de l'exception dans la file d'attente du pool de threads, puis l'éclatement de la file d'attente, provoquant le MOO. Selon cette idée, j'ai modifié le code, mis à niveau et continué à observer, mais la même explosion lente de SQL et du centre utilisateur s'est toujours produite. Puisqu’il n’y a aucune anomalie, le point de suspicion b peut également être exclu.

(9) À ce stade, il est presque certain que le point C est suspecté, c'est-à-dire l'endroit où la requête de table complète de la grande table de l'entreprise A est appelée, ce qui rend la mémoire du centre utilisateur trop grande et le JVM n'a pas le temps de le recycler, puis fait directement exploser le CPU. Dans le même temps, étant donné que les données entières de la table sont trop volumineuses, le temps de verrouillage des métadonnées pendant la requête est trop long, ce qui empêche la connexion de se libérer à temps et finit par être presque épuisée.

(10) Les conditions de vérification nécessaires à l'interrogation de la grande table de l'entreprise A ont donc été modifiées et redéployées pour l'observation en ligne. Il y a eu un problème avec le positionnement final.

2. Cause du problème

Parce que lors du changement de table métier B, vous devez envoyer un message MQ (synchroniser les données de la table métier A avec ES). Après avoir reçu le message MQ, interrogez les données liées à la table métier A, puis synchronisez les données avec Elasticsearch.

Mais lors du changement de la table métier B, les conditions nécessaires requises pour la table métier A n'ont pas été transférées, et je n'ai pas non plus vérifié les conditions nécessaires, ce qui a abouti à une analyse complète de la grande table de l'entreprise A. Parce que :

某些同事说，“这个条件肯定会传、肯定有值、肯定不为空...”，结果我真信了他！！！

En raison des changements fréquents dans la table de l'entreprise B à cette époque, davantage de messages MQ ont été envoyés et consommés, ce qui a déclenché des analyses de table plus complètes de la grande table de l'entreprise A, ce qui a conduit à des temps de verrouillage des métadonnées Mysql plus longs. long et le nombre final de connexions était excessif.

Dans le même temps, les résultats de la requête de grande table de l'entreprise A sont renvoyés à chaque fois dans la mémoire du centre utilisateur, déclenchant ainsi le garbage collection JVM, mais ils ne peuvent pas être recyclés au final, la mémoire et le CPU sont épuisés. .

Quant à l'exception selon laquelle Redis ne peut pas obtenir la connexion, ce n'est qu'une bombe fumigène. Parce qu'il y a trop d'événements MQ envoyés et consommés, un petit nombre de threads ne peuvent pas obtenir la connexion Redis en un instant.

Enfin, j'ai ajouté la vérification des conditions dans le code pour la consommation des événements MQ, ainsi que la vérification des conditions nécessaire au niveau de la table de requête A, je l'ai redéployée en ligne et j'ai résolu le problème.

3. Résumer les leçons

Après cet incident, j'ai également résumé quelques leçons et les partage avec vous :

(1) Soyez toujours attentif aux problèmes en ligne. Une fois qu'un problème survient, vous ne devez pas le laisser partir et enquêter rapidement. Ne doutez plus du problème de la gigue du réseau. La plupart des problèmes n’ont rien à voir avec le réseau.

(2) La table des grandes entreprises elle-même doit être consciente de la protection et la requête doit ajouter la vérification des conditions nécessaires.

(3) Lors de la consommation de messages MQ, vous devez vérifier les conditions nécessaires et ne faire confiance à aucune source d'information.

(4) Ne croyez jamais certains collègues qui disent : « Cette condition sera certainement transmise, elle aura certainement une valeur, elle ne sera certainement pas vide », etc. Afin de garantir la haute disponibilité et la stabilité du système, nous reconnaissons uniquement le code et non les personnes.

(5) Séquence générale de dépannage lorsque des problèmes surviennent :

• CPU de base de données, blocage, SQL lent.
• CPU, mémoire et journaux de la passerelle et des composants principaux de l'application.

(6) L'observabilité commerciale et les alarmes sont essentielles et doivent être complètes, afin que les problèmes puissent être découverts et résolus plus rapidement.

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!