table des matières
Un paramètre raisonnable de délai d'expiration du réseau
Séparation des activités principales et non essentielles
Trois configurent raisonnablement le nombre de threads tomcat
Essayez de ne pas réessayer dans les quatre codes
Cinq dépendances non essentielles pour l'affaiblissement
Six rationalisation des transactions de base de données
Sept points d'optimisation des performances SQL
8. Essayez de faciliter le processus en ligne
Neuf limitation de courant, fusion, dégradation, mise en file d'attente pour gérer le trafic anormal
Dix fonctions de journalisation et de surveillance parfaites
Cet article explique principalement quelques expériences et résumés sur la haute disponibilité et la construction haute performance.
Un paramètre raisonnable de délai d'expiration du réseau
1.1 Quelle est la période d'expiration de l'appel réseau?
Par exemple, des requêtes réseau entre serveurs d'applications, entre serveurs d'applications et serveurs redis, entre serveurs d'applications et serveurs mq, ces requêtes réseau ont généralement trois délais d'expiration:
- connectRequestTimeout: le client obtient le délai d'expiration de la connexion à partir du pool de connexions.
- connectTimeout: délai d'expiration pour l'établissement d'une connexion entre le client et le serveur.
- socketTimeout: délai d'expiration du délai de lecture des données par le client et le serveur.
1.2 Pourquoi dois-je définir le délai d'expiration?
Comme le pool de connexions système ou les ressources du pool de threads sont limités, en supposant qu'aucun délai d'expiration n'est défini, en raison de services en aval lents ou de services en aval anormaux, un grand nombre de threads attendront bêtement le retour des services en aval.
Certaines requêtes normales seront attendues ou rejetées, la réponse du service ralentira, le débit baissera, le QPS sera plus bas et l'expérience utilisateur sera pire. Cette situation peut être évitée en définissant un délai d'expiration.
1.3 Comment définir raisonnablement le délai d'expiration?
Le principe simple est: socketTimeout, connectTimeout, connectRequestTimeout 3 timeouts, pas plus de 300ms, aussi courts que possible si le système peut accepter.
Le délai d'expiration peut être défini en fonction des 99 lignes du système . La ligne dite 99 est le temps minimum requis pour satisfaire 99% des requêtes réseau. Pour faire simple, supposons que nous ayons une interface qui demande 10 000 fois par jour,
Le temps minimum requis pour calculer 9 900 demandes est appelé 99 lignes. Pour des calculs spécifiques, veuillez vous reporter à cet article ( https://blog.csdn.net/brucewong0516/article/details/80205422 ).
Redis lit et écrit normalement en 2-3 ms, et le délai d'expiration doit être défini plus court, essayez de ne pas dépasser 50 ms. La même chose est vraie pour le délai d'expiration de mq.
Séparation des activités principales et non essentielles
Chaque entreprise a une activité principale et une activité secondaire. Le lien principal peut être trié pour l'activité principale. Ce que l'on appelle le lien principal doit être l'activité la plus précieuse de l'entreprise. L'activité principale ne peut appeler l'activité principale que sur le lien.
Les activités non essentielles ne peuvent appeler que les activités non essentielles. Si l'entreprise le peut, réalisez le déploiement d'une salle informatique double ou même de plusieurs salles informatiques.
Trois configurent raisonnablement le nombre de threads tomcat
Configurez raisonnablement le nombre de threads. Par exemple, les threads gourmands en ressources processeur peuvent être moins configurés, et ceux exigeants en E / S peuvent être configurés davantage. Pour plus de détails, veuillez consulter cet article ( https://blog.csdn.net/jack1liu/article/details/100511226 ).
Essayez de ne pas réessayer dans les quatre codes
S'il n'y a pas de raison particulière, veuillez ne pas réessayer dans le code. La nouvelle tentative doit être une tentative professionnelle dans la mesure du possible, et le personnel en amont effectuera l'opération de nouvelle tentative.
Pourquoi ne pas réessayer dans le code?
Si vous réessayez dans le code, ce bloc est sujet à une amplification du débit, généralement 1 fois la quantité, si vous réessayez 5 fois, le débit sera 5 fois plus élevé que d'habitude. Il est facile d'arrêter le service.
Cinq dépendances non essentielles pour l'affaiblissement
Qu'est-ce que la faible dépendance?
La soi-disant dépendance faible consiste à dépendre faiblement de processus qui ont moins d'impact sur le processus principal.
Par exemple, lorsqu'une exception de délai d'expiration se produit dans mq / redis, si elle n'affecte pas la fonction principale, vous devez intercepter l'exception et ne pas la lancer dans la couche supérieure. par exemple:
String value = redis.get(“key”);
if(value == null) {
value = dao.getOneColumn(“”);
}
}S'il n'y a pas de capture faiblement dépendante de redis, lorsque redis échoue, une exception sera lancée directement à la couche supérieure et les données ne peuvent pas être lues à partir de la base de données.
En plus de la tolérance aux pannes de mq, comment gérer les messages perdus lorsque mq n'est pas disponible? Par exemple, modifiez le mq pour enregistrer le journal et le traiter ultérieurement.
Six rationalisation des transactions de base de données
Les opérations au sein d'une transaction doivent être aussi peu nombreuses que possible pour réduire le temps d'exécution de la transaction et il ne doit y avoir aucun appel RPC.
Sept points d'optimisation des performances SQL
7.1 Comment définir le SQL lent?
En théorie, l'exécution SQL côté utilisateur doit se faire dans les 10 ms, et plus de 50 ms peuvent être classées comme SQL lent.
7.2 Quelle est la limite appropriée pour le nombre de requêtes SQL?
Par exemple, la limite ne peut pas dépasser 100 ou 200, et la limite id de in est également 100 ou 200.
7.3 Comment vérifier que le SQL nouvellement ajouté ne pose aucun problème?
Utilisez expliquer pour afficher le plan d'exécution de SQL.
Ajoutez des index aux champs de requête associés pour accélérer la requête.
8. Essayez de faciliter le processus en ligne
Par exemple, pour la migration de la base de données, deux points essentiels doivent être pris en compte dans la conception du programme et le processus en ligne: un contrôle maximal de la zone d'impact et une récupération rapide .
Comment contrôler au maximum la zone d'influence?
- Vous pouvez envisager le processus en niveaux de gris et augmenter progressivement le volume.
- Afin de vérifier la fonction, vous pouvez ajouter une liste blanche, etc.
Comment restaurer la fonction rapidement ?
- Ajoutez des commutateurs dynamiques pour restaurer rapidement les fonctions.
- Préparez-vous à l'avance et rétablissez le plan en ligne.
Neuf limitation de courant, fusion, dégradation, mise en file d'attente pour gérer le trafic anormal
L'auteur a rencontré le problème suivant: le service est temporairement indisponible en raison d'un trafic anormal. Pour plus d'informations, consultez ( https://blog.csdn.net/jack1liu/article/details/112135898 ).
Bien entendu, les technologies de fusion, de dégradation et de mise en file d'attente peuvent également être utilisées pour un trafic anormal dans le service. Tant que le problème peut être résolu, tout va bien.
Dix fonctions de journalisation et de surveillance parfaites
Nous devons imprimer les données de journal raisonnables et nécessaires.
10.1 Qu'est-ce qu'un journal raisonnable et nécessaire?
Les journaux qui peuvent résoudre les problèmes commerciaux et résoudre les problèmes système sont raisonnables et nécessaires.
10.2 Pourquoi avons-nous besoin d'améliorer la fonction de surveillance?
S'il n'y a pas de surveillance, nous aurons le sentiment que nos services fonctionnent réellement à vide.S'il y a un problème, la surveillance peut nous aider à trouver, reproduire et résoudre le problème plus rapidement et plus efficacement.