Does NFS slow down consumer message processing? - ApsaraMQ for Kafka

Lorsqu'un consommateur écrit des messages de manière synchrone dans un système de fichiers réseau (NFS) au sein de la boucle principale d'interrogation, le traitement des messages ralentit et peut bloquer totalement la consommation.

Pourquoi le NFS bloque la consommation

Les consommateurs Kafka utilisent un modèle basé sur l'extraction : le consommateur appelle poll() pour récupérer un lot de messages, les traite, puis rappelle poll(). Toute opération lente exécutée dans la boucle d'interrogation, telle qu'une écriture NFS synchrone, retarde l'appel suivant à poll() et réduit le débit.

Le NFS aggrave ce problème de deux manières :

Le NFS est plus lent que le stockage local. La latence d'écriture sur un système de fichiers réseau partagé est supérieure à celle d'un disque connecté localement, ce qui augmente directement le temps de traitement par message.
Plusieurs consommateurs se disputent les ressources NFS. Bien que le NFS prenne en charge l'accès simultané de plusieurs consommateurs, chacun d'eux entre en concurrence pour la même bande passante réseau et les mêmes opérations d'E/S disque. Plus le nombre de consommateurs partageant le NFS est élevé, plus les performances de chaque consommateur se dégradent.

Dissocier la consommation du stockage

Deux approches permettent de résoudre ce problème. Utilisez-les indépendamment ou conjointement.

Séparer la consommation et le stockage en deux threads (recommandé)

Découplez l'extraction des messages de leur stockage en utilisant deux threads indépendants :

Thread de consommation : appelez poll(), traitez les messages et placez les résultats dans une file d'attente en mémoire (telle que BlockingQueue en Java ou queue.Queue en Python).
Thread de stockage : lisez les données depuis la file d'attente en mémoire et écrivez les résultats sur le NFS.

Cette conception empêche les écritures NFS de bloquer le thread de consommation, qui continue d'extraire les messages à pleine vitesse.

+-----------------------+      +----------------+      +-----------------------+
| Consumption thread    |      | In-memory      |      | Storage thread        |
|                       |----->| queue          |----->|                       |
| poll() + process      |      | BlockingQueue  |      | Write to NFS          |
+-----------------------+      +----------------+      +-----------------------+

Surveillez la taille de la file d'attente en mémoire. Si le thread de stockage ne parvient pas à suivre le rythme, la file d'attente augmente sans limite. Définissez une capacité maximale pour la file d'attente et établissez une stratégie de rétropression, comme le blocage du thread de consommation lorsque la file est pleine.

Utiliser des disques cloud locaux avec une synchronisation NFS asynchrone

Attachez un ultra-disque ou un disque SSD à chaque consommateur et écrivez les résultats sur le stockage local plutôt que directement sur le NFS. Utilisez ensuite un thread ou un outil distinct pour synchroniser de manière asynchrone les données des disques cloud locaux vers le NFS en arrière-plan.

Cette approche offre deux avantages :

Élimine la contention NFS pendant la consommation. Chaque consommateur écrit sur son propre disque local, ce qui supprime la concurrence pour les ressources NFS partagées.
Empêche les écritures NFS synchrones de bloquer la boucle d'interrogation. Le processus de synchronisation asynchrone s'exécute de manière indépendante, de sorte que la latence du NFS n'affecte pas le traitement des messages.