par Fadi Obeid, ingénieur principal & Tech Lead, produits publicitaires

Si vous avez travaillé sur ou avec le temps réel, vous avez probablement dû vous occuper de l'enregistrement des événements. Chez ShareThis, nous travaillons en temps réel - nous recueillons les signaux sociaux au fur et à mesure qu'ils se produisent, nous appliquons une logique commerciale à ces signaux et nous transformons finalement ces signaux en règles complexes de ciblage publicitaire. 

Dans ce post, nous allons couvrir l'enregistrement de l'événement à l'échelle aspect. Une version simplifiée de notre pipeline ressemble à ce qui suit:

Le flux de Kafka est de pompage autour de 800 000 001 000 000 000 événements/jour. Chaque événement se développe en moyenne de 12 événements virtuels, de sorte que la logique métier à l'intérieur de la grappe de consommateurs Kafka devra traiter et d'évaluer 9-12 milliards d'événements par jour, et enregistre les événements de qualification sur le disque.

Au départ, nous avons eu une cartographie 1 × 1 de l'événement RAW à l'événement virtuel qui n'était pas une grosse affaire puisque nous avions "assez de machines". La capacité du cluster était de 3 instances C3. XLarge et était sauvegardée par un enregistreur synchrone.

Avec le temps, la cartographie a augmenté-de 1 × 1 à 1 × 3 et ainsi de suite. Chaque boîte de Kafka dans le cluster était en cours d'exécution avec 25 threads, et à la charge, l'effet de verrouillage de l'opération d'écriture comme on le voit dans cet extrait de code ont été paralysant. L'exécuteur de pool de threads était en retard dans sa capacité de service de la demande entrante, et le décalage Kafka a commencé à la traîne, parfois jusqu'à un point où il ne pourrait jamais rattraper.

Un profil des threads en cours d'exécution a montré que les fils sont bloqués presque tout le temps, Aïe!

Nous avons commencé à examiner nos options. Notre liste est descendue à: 

• Ajouter d'autres machines
• Enregistreur asynchrone du cru
• Log4j2 asynchrone + disrupteur + RandomAccessFile

Nous sommes passés par les avantages et les inconvénients et a atterri sur Log4j2. Nous l'avons comparé, et les résultats ont été très impressionnants. Pour les besoins de ce poste, nous sommes montrant deux graphiques: le premier montre le débit à faible charge, et le deuxième montre le débit à haute charge. La belle partie était de savoir comment il était facile de le câble dans le projet existant, le soutien et la documentation suffisante.

En conclusion, nous pouvons dire en toute sécurité que notre choix «log4j2 Asynchronous + disrupteur + RandomAccessFile» pour l'exploitation forestière était le bon. Si vous traversez un processus similaire, nous vous recommandons fortement de profiler votre application, de présenter vos options et de les comparer.