Milliarden von Events pro Sekunde verarbeiten, ohne die Latenz zu killen

Stellen Sie sich vor: Sie müssen Banktransaktionen in Echtzeit während des Zahlungsvorgangs auf Betrug prüfen. Sie haben nur wenige Millisekunden Zeit für eine Entscheidung. Apache Kafka streamt ununterbrochen Events, aber für jedes einzelne müssen Sie die Kundenhistorie aus der Datenbank abrufen. Wenn Sie für jede Nachricht eine traditionelle PostgreSQL- oder MySQL-Abfrage stellen, wird das System unter der Last sofort zusammenbrechen.

Dies ist eine häufige Sackgasse, in die Entwickler beim Entwerfen von Hochlastsystemen geraten. Ein regulärer Cache wie Redis beschleunigt einzelne Key-Reads, aber wenn es darum geht, komplexe Business-Logik und Analysen auf Basis eines Daten-Streams aufzubauen, stößt er an seine Grenzen. Sie sind gezwungen, Caches, Message-Broker und Drittanbieter-Processing-Engines zusammenzuführen. An diesem Punkt lohnt es sich, einen Blick auf Hazelcast zu werfen.

Hazelcast kombiniert verteilten In-Memory-Speicher und eine Stream-Processing-Engine in einem einzigen System. Anstatt ein Konstrukt aus drei verschiedenen Services zusammenzubauen, erhalten Sie eine einheitliche Plattform, die Daten im Flug aufnehmen, anreichern und analysieren kann.

Was passiert innerhalb der Plattform

Das Herzstück der Plattform ist die Jet-Engine. Sie ist verantwortlich für den Aufbau von Datenverarbeitungs-Pipelines. Jet kann gleichermaßen gut mit kontinuierlichen Streams und statischen Datensätzen arbeiten, wie z.B. Buckets in Amazon S3 oder Tabellen in einer relationalen Datenbank.

Die Performance-Metriken sind hier interessant. Ein einzelner Hazelcast-Node kann 10 Millionen Events pro Sekunde aggregieren und dabei die Latenz unter 10 Millisekunden halten. Wenn Sie die Server zu einem Cluster zusammenfügen, skaliert der Durchsatz auf eine Milliarde Events pro Sekunde.

Um Abfragen gegen Daten-Streams zu schreiben, müssen Sie nicht in Low-Level-Java-APIs eintauchen. Die Plattform unterstützt Standard-SQL. Sie können eine vertraute SELECT gegen den eingehenden Daten-Stream schreiben, ihn mit einer In-Memory-Tabelle verknüpfen und das Ergebnis sofort an den Zielservice weiterleiten.

So sieht das Verbinden externer Quellen aus. Out-of-the-box erhalten Sie eine Reihe von Konnektoren:

• Apache Kafka und JMS für die Arbeit mit Queues
• Hadoop und Amazon S3 für den Zugriff auf Dateispeicher
• Relationale Datenbanken über Standard-JDBC
• Python-Modelle für die Ausführung von Machine Learning direkt in der Pipeline

Verteilter Speicher und Koordination

Wenn Sie die Stream-Analytik aus der Gleichung herausnehmen, bleibt Hazelcast ein verteilter Key-Value-Store. Daten werden über Cluster-Nodes als Partitionen verteilt. Entwickler haben Zugriff auf vertraute Java-Strukturen (IMap, IQueue, ITopic), mit dem einzigen Unterschied, dass sie über das Netzwerk verteilt sind. Point-Lookups nach Key dauern Mikrosekunden.

Für Datenbankoperationen werden klassische Caching-Muster unterstützt: Read-Through, Write-Through und Write-Behind. Bei Verwendung von Write-Behind speichert die Anwendung Daten ausschließlich im RAM von Hazelcast, und die Plattform schreibt sie asynchron auf die Festplatte und in die Hauptdatenbank. Wenn das relationale DBMS vorübergehend ausfällt, wird Ihre Anwendung weiterhin Anfragen ohne Ausfälle akzeptieren.

Ein separates Feature ist die Microservice-Koordination. Hazelcast kann verteilte Locks verwalten, eindeutige ID-Sequenzen ausgeben und gemeinsame Zähler pflegen. Dadurch entfällt die Notwendigkeit, einen separaten Apache ZooKeeper-Cluster für alltägliche Synchronisierungsaufgaben bereitzustellen und zu warten.

Wie man das Projekt baut und ausführt

Der Quellcode des Projekts ist in Java geschrieben. Für den Build aus dem Quelltext wird JDK 17 oder neuer benötigt. Der einfachste Weg, das Projekt zu bauen, ist das Maven-Wrapper-Script zu verwenden:

git pull origin master
./mvnw clean package -DskipTests

Der vollständige Build mit allen Checks kann eine Weile dauern. Wenn Sie nur schnell lokale Änderungen verifizieren müssen, übergeben Sie das -Dquick-Flag:

./mvnw clean package -DskipTests -Dquick

Dieser Parameter deaktiviert die Javadoc-Generierung, Checkstyle-Checks und Builds von sekundären Modulen.

Die Test-Situation ist interessant. Das Repository enthält Tausende von Tests, die in drei Profile unterteilt sind:

• Das Standardprofil ./mvnw test führt schnelle Integrationstests aus.
• Das nächtliche Profil ./mvnw test -P nightly-build enthält langsame Tests, die nicht parallel ausgeführt werden können.
• Das vollständige Profil ./mvnw test -P all-tests führt sequenziell alle Checks unter Verwendung des Netzwerks aus.

Einige Tests sind von Docker abhängig. Wenn Docker nicht auf Ihrem Rechner installiert ist, werden diese Tests fehlschlagen. Um sie zu deaktivieren, verwenden Sie den -Dhazelcast.disable.docker.tests-Parameter. Beim Erstellen eines Pull Requests führt der CI-Server des Projekts die vollständige Suite aus, daher ist es lokal ausreichend, nur Tests für Ihr eigenes Modul auszuführen.

Sie können Clients nicht nur in Java schreiben. Die Community und das Unternehmen pflegen offizielle Bibliotheken für Python, Node.js, .NET, C++ und Go.

Lizenz und ein paar praktische Feinheiten

Der Code im Repository ist in zwei Teile aufgeteilt. Der Kern wird unter der permissiven Apache License 2.0 vertrieben. Einige Enterprise-Features und Module sind jedoch durch die Hazelcast Community License geschützt. Sie verbietet die Nutzung des Codes zur Erstellung kostenpflichtiger verwalteter Services (Cloud Service Provider), die mit dem Cloud-Produkt des Unternehmens konkurrieren.

Der zweite Punkt sind die Ressourcenanforderungen. Da sich alle Hot-Daten im RAM befinden, müssen Sie eine erhebliche Menge an Speicher erwerben, um mit großen Volumina zu arbeiten. Außerdem sollten Sie in einer Java-Umgebung den Garbage-Collector sorgfältig konfigurieren, um Pausen bei der Bereinigung von Gigabytes an Speicher zu vermeiden. Hazelcast-Entwickler mildern dieses Problem jedoch mit Off-Heap-Speicher, der Daten außerhalb des Java-Heaps ablegt.

Für wen lohnt sich ein Blick auf Hazelcast

Die Plattform performt gut dort, wo Echtzeit-Event-Response wichtig ist:

• Betrugsprävention und Scoring im Fintech-Bereich
• Verarbeitung von Telemetrie und hochfrequenten IoT-Signalen
• Berechnung von Preisen und Rabatten im E-Commerce genau im Moment des Klicks eines Kunden
• Synchronisierung von Daten zwischen verteilten Rechenzentren (WAN-Replikation)

Wenn Sie nur einen einfachen Cache für ein paar Endpoints benötigen, wäre Hazelcast Overkill: Ein einfacheres Redis würde diese Aufgabe problemlos erledigen. Aber wenn Ihr Projekt auf eine Größe gewachsen ist, bei der Stream-Analytik auf verteilten Speicher treffen muss, ohne ständig auf die Festplatte zuzugreifen, wird Hazelcast Ihnen Monate der Entwicklung ersparen.