Protocols & Binary Serialization
Prüfen Sie einen Schlüssel und die Gesamtzahl der Partitionen mit Java-kompatiblem Murmur2.
Leerzeichen und Zeilenumbrüche bleiben erhalten. Eine leere Bytefolge ist gültig. Für einen fehlenden Schlüssel wählen Sie null.
68 65 6c 6c 6f
Die Berechnung bleibt in diesem Browser. Schlüssel werden weder gesendet noch gespeichert; es gibt keine Verbindung zum Kafka-Cluster.
Gilt für Java-kompatibles Murmur2 mit Schlüssel. Eine explizite Partition, ignorierte Schlüssel, andere Serializer oder Partitioner können das tatsächliche Ziel ändern.
Berechnung abgeschlossen.
Wer eine Kafka-Partition berechnen möchte, muss zunächst die Serialisierung kennen. Eine sichtbare Kundennummer kann als Text, Integer oder strukturierte Nachricht übertragen werden. Dieser Rechner zeigt die Bytes und Zwischenwerte, damit sich ein Unterschied im Schlüssel von einer anderen Routingregel trennen lässt.
Ein Partitionsschlüssel ist für die Hashfunktion eine Bytefolge. Ein zusätzliches Leerzeichen oder ein Zeilenumbruch aus dem Log gehört dazu. Liegen bereits serialisierte Daten vor, geben Sie diese als Hex oder Base64 ein, statt ihre lesbare Darstellung nachzubauen.
Sie können eine Kafka-Partition berechnen und zugleich die zugrunde liegenden Bytes kontrollieren. Drei Eingabeformate führen bei identischen Bytes zum gleichen Hashwert. Die Hexansicht macht Nullen, Zeilenumbrüche und mehrbyteige Zeichen sichtbar, die beim Vergleich zweier Textfelder leicht übersehen werden.
Ein leerer UTF-8-String ergibt ein vorhandenes Array mit null Bytes. Ein null-Schlüssel hat dagegen keine Bytefolge. Der erste Fall lässt sich deterministisch hashen; der zweite benötigt den Laufzeitzustand des Producers. Deshalb erscheint für null keine erfundene Zielnummer.
UTF-8 erhält Leerzeichen und Zeilenumbrüche. Hex erlaubt ASCII-Leerraum, benötigt aber vollständige Bytepaare ohne 0x. Standard-Base64 erfordert das passende Padding. Ein Wechsel der Codierung interpretiert die vorhandene Eingabe neu und wandelt sie nicht automatisch um.
12 ist ein Beispielwert, keine Empfehlung für die Dimensionierung. Die Nummerierung beginnt bei null: 12 Partitionen ergeben die Ziele 0 bis 11. Ändert sich die Anzahl, kann derselbe Hash einen anderen Rest und damit ein anderes zukünftiges Ziel liefern.
Laden Sie abc oder foobar aus den Testvektoren und vergleichen Sie den angezeigten Hash mit dem festen Sollwert. Automatisch wird nach 350 ms gerechnet. Bei deaktivierter Automatik startet Strg/Cmd + Enter; veraltete Ergebnisse bleiben vom Export ausgeschlossen.
Der Seed lautet 0x9747b28c. Vier-Byte-Blöcke werden Little Endian gelesen, Produkte auf 32 Bit begrenzt. Die Anzeigen mit und ohne Vorzeichen beschreiben dieselben Bits. Für das Routing wird das Vorzeichenbit mit 0x7fffffff gelöscht; der Absolutbetrag wäre eine andere Rechnung.
Hex und Standard-Base64 bilden beliebige Bytes einschließlich 00 und ff ab. Ungerade Hexlängen, falsches Padding und ungültige abschließende Base64-Bits werden abgelehnt. Text bleibt hinsichtlich Großschreibung, Leerraum und Unicode-Normalform unverändert, damit keine stillen Korrekturen den Hash verschieben.
abc, foobar und 21 enthalten erwartete Hashwerte aus Apache Kafka. Die Vorschau zeigt zunächst 100 Bytes und lässt sich jeweils um 100 erweitern. Im JSON-Bericht stehen alle Bytes, Codierung, Schlüsseltyp, Partitionsanzahl, Algorithmus und die numerischen Zwischenwerte für den Vergleich mit Logs.
Für das gewählte schlüsselbasierte Verfahren berechnen Sie Murmur2 über die serialisierten Bytes, löschen das Vorzeichenbit und bilden den Rest zur Gesamtzahl. abc ergibt den signierten Hash 479470107 und bei 12 Partitionen das Ziel 3. Die tatsächliche Anzahl müssen Sie anhand der Topic-Metadaten prüfen.
Ja. Sehr viele Schlüssel teilen sich eine endliche Anzahl von Zielen. Dafür müssen die vollständigen 32-Bit-Hashes nicht identisch sein: Verschiedene positive Hashwerte können denselben Rest ergeben. Die gemeinsame Partition beweist daher weder gleiche Schlüssel noch eine vollständige Hashkollision.
Vergleichen Sie Bytes, Partitionsanzahl und Partitioner-Konfiguration. Unterschiedliche Clients können andere Algorithmen und Serializer verwenden. Auch eine explizite Partition oder das Ignorieren von Schlüsseln kann die Ursache sein. Ein Consumer-Rebalancing ändert die Zuständigkeit für Partitionen, aber nicht diese Hashformel.
Nein. Ob ein Schlüssel nötig ist, hängt von den Anforderungen an Gruppierung und Reihenfolge ab. Ohne Schlüssel kann ein Producer ebenfalls senden. Das Ziel ergibt sich dann jedoch nicht allein aus der hier berechneten Murmur2-Formel. Eine leere Zeichenfolge ist ein eigener, davon verschiedener Fall.
Das hängt von Client, Version, Konfiguration und Laufzeitzustand wie der Batchbildung ab. Java-Producer können Sticky-Verhalten nutzen; andere Clients folgen ihren eigenen Regeln. Der Rechner gibt für null keine feste Partition aus und setzt auch nicht pauschal ein älteres Round-Robin-Verfahren voraus.
Die Kafka-Variante verwendet den festen Seed 0x9747b28c. Identische Bytes erzeugen deshalb über Programmstarts hinweg denselben Hash. Das endgültige Ziel kann sich trotzdem ändern: Eine andere Partitionsanzahl verändert den Modulo-Schritt, ein anderer Partitioner gegebenenfalls die gesamte Zuordnung.
Eine unerwartete Berechnung entdeckt?
Jetzt eine Kafka-Partition berechnen: Verwenden Sie die Bytes Ihres Serializers und vergleichen Sie die Zwischenwerte mit der Routingimplementierung des Producers.