© Enkel/Shutterstock.com
Concurrency mit Vert.x

Reaktives Paradigma


Auch wenn Java und die JVM Nebenläufigkeit mittlerweile gut handhaben können, kann es sich trotzdem lohnen, ein wenig Hilfe ins Boot zu holen. Das Vert.x-Framework greift Entwicklern beim Thema Concurrency unter die Arme.

Die JVM hat sich als Plattform etabliert, die sowohl den Anforderungen von modernen Datenanwendungen mit hohem Durchsatz bei niedriger Latenz als auch den rechenintensiven Workloads gerecht wird. Leider hat sich das Low-Level-Threading-Modell von Java als unpassende Ergänzung zu seinem klassischen imperativen Paradigma herausgestellt. Um das Problem des Low-Level-Thread-Managements anzugehen und dennoch ein ausgefeiltes Concurrency-Programmiermodell anzubieten, gab es in letzter Zeit Anstrengungen auf verschiedenen Ebenen.

Vert.x ist eine dieser Bemühungen [1]. Vert.x basiert auf einer Node.js-ähnlichen Single-I/O-Eventschleife. Es bietet ein Programmiermodell, das auf einem Taskkontext basiert und gleichzeitig die Last der zugrunde liegenden Threadverwaltung von der Schulter des Programmierers nimmt. Da es eventgetriebene Nachrichten nutzt, bedeutet das, dass die Events durch I/O-Ereignisse ausgelöst werden. Der Task wartet also nicht und blockiert auch nicht. Das gesamte Toolkit ist modular aufgebaut und der Kern weniger als 1 MB groß. Eine solche Architektur ermöglicht einfache Erweiterungen, ohne dass das gesamte Design unter dem eigenen Gewicht zusammenbricht. Besser noch, eine auf Vert.x-basierte Anwendung kann sowohl als eigenständiges JAR- als auch als HA-Cluster deployt werden. Innerhalb dieses Clusters kann jedes Verticle Nachrichten an andere Verticles senden. Wie cool ist das denn!

Unter der Haube sind die Vert.x-APIs eventgesteuert. So kommt das Framework als reaktive Plattform daher. Definierte Handler werden über einen Event-Loop-Thread aufgerufen. Ein Event-Loop kann sich um verschiedene Events kümmern und liefert so eine gute Performance. Das Konzept, dass ein einzelner Thread effizienter sein kann als mehrere Threads, kann am Anfang etwas kontraintuitiv sein.

Vollkommen asynchroner Fluss

Eine typische App hat in der Regel viele blockierende Roundtrips. Beispiele hierfür sind Lese/Schreibzugriffe auf persistente Datenspeicher oder Remote-Ressourcen. Um diesen Anforderungen gerecht zu werden, unterstützt Vert.x verschiedene asynchrone Module für eine optimale Performance. Aber der Programmierer kann leicht aus einem Worker-Thread aussteigen und die meisten Aufgaben auf die altmodische blockierende Art und Weise erledigen, ohne die Eventschleife anzuhalten.

Um all das Beschriebene besser zu verstehen, schauen wir uns ein Beispiel mit einem realen Szenario an. Wir werden eine auf Vert.x basierte Anwendung analysieren, die die Async-Module verwendet, um mit einem Persistenzspeicher und einer Remote-Ressource zu kommunizieren. Der gesamte Quellcode ist unter der Apache-2.0-Lizenz veröffentlicht und wird auf GitHub gehostet [2]. Für das Set-up brauchen wir mindestens Docker 17.x, JDK 1.8 und Maven 3 auf dem System. Wir werden einfach nur zwei REST-Ressourcen abfragen. Zuerst suchen wir die Namen verfügbarer Wikipedia-Artikel im Datenspeicher unseres Servers. Hier werden wir sehen, wie das Async-MySQL-Modul von Vert.x uns dabei hilft, nicht blockierende Lesezugriffe mit...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang