Migrer de LinkedBlockingQueue vers le perturbateur LMAX

Question

Y a-t-il un exemple de code pour migrer de la LinkedBlockingQueue standard vers l'architecture Disruptor de LMAX ? J'ai une application de gestion d'événements (un producteur unique, plusieurs consommateurs) qui pourrait bénéficier du changement.

Est-ce même logique lorsque mon objectif est de maximiser le débit plutôt que de minimiser la latence ?

Answer 1

Mentaqueue fournit une file unique producteur unique consommateur basée sur les mêmes idées - http://mentaqueue.soliveirajr.com/Page.mtw, vous pourriez examiner le code, bien que je ne l'ai jamais utilisé moi-même.

Disruptor fournit d'emblée deux techniques ici - je ne vais pas encore entrer dans le code mais je peux le faire si vous en avez besoin.

1. Il permet une façon de séquencer les gestionnaires d'événements, et vous pourriez le configurer de sorte que chaque gestionnaire traite toutes les requêtes en parallèle ; chaque requête est traitée par chaque gestionnaire.

2. Une implémentation de pool de travailleurs qui permettrait à un pool de threads de travailleurs de traiter chacune une requête ; chaque requête serait traitée une fois à partir d'un pool de threads.

Si vous avez identifié que la mise en file d'attente prend beaucoup de temps ou si vous avez des problèmes importants de contention temporelle (verrous / synchronisation), je vous recommande vivement de regarder le Disruptor. Vous obtiendrez les meilleurs avantages en examinant si des ajustements à votre architecture pourraient conduire à une utilisation propre du Disruptor.

Oui, réduire la latence des transactions devrait aider à augmenter le débit, donc cela pourrait avoir du sens, mais cela dépend de ce qui ralentit votre débit. Cela deviendra un commentaire très général - que vous devriez identifier la zone de votre application qui freine le débit.

Les indicateurs qui me conduiraient à utiliser le Disruptor seraient - beaucoup de tâches à exécution rapide traitées de manière similaire, une contention sur la mémoire, une exigence de séquençage, du streaming ou une forte E/S (qui pourrait bénéficier du regroupement).