ForHosting KIT · Entwickler-Tools

Rendezvous-Hashing-Knotenwähler

Ordnen Sie einen Schlüssel einem Knoten Ihrer Liste zu: user:42 landet bei cache-a, cache-b und cache-c auf cache-a und bleibt dort, solange sich Knoten und Seed nicht ändern. Die Punktzahl jedes Knotens wird angezeigt, damit Sie die Wahl prüfen können. Kostenlos in Ihrem Browser.

Kostenlos
Läuft in Ihrem Browser
Ohne Anmeldung
Ihre Daten bleiben auf Ihrem Gerät

Im Browser ausführen – kostenlos API ansehen

Nutzen Sie es über WebAPIE-MailTelegramApp bald

Rechenbeispiel

Wenn Sie eingeben

Key: user:42
Knoten: cache-a, cache-b, cache-c

Erhalten Sie

Startwert
Ausgewählt: cache-a
Anzahl der Knoten: 3

Rendezvous-Hashing, auch highest random weight hashing genannt, weist jedem Schlüssel genau einen Knoten aus der aktiven Menge zu — ohne Ring virtueller Knoten. Für jeden Kandidatenknoten hasht der Algorithmus den Schlüssel zusammen mit der Knoten-ID, ordnet die Bewertungen und wählt den Gewinner. Wenn ein Knoten hinzukommt oder ausscheidet, wandern nur Schlüssel, die den ausgeschiedenen Knoten bevorzugten oder den Neuankömmling jetzt bevorzugen; der Rest bleibt, sodass Cache-Trefferraten und Shard-Besitz bei Mitgliedschaftswechseln stabil bleiben. Dieser Rendezvous-Knotenwähler akzeptiert einen Routing-Schlüssel, eine Liste von Knoten-IDs, einen optionalen Cluster-Seed und optionale positive Gewichte und liefert den gewählten Knoten plus die vollständige Bewertungstabelle, damit Sie Platzierung prüfen oder testen können.

Wie Rendezvous-Hashing einen Knoten für einen Schlüssel wählt

Consistent Hashing popularisierte die Idee, Schlüssel auf einem Ring zu platzieren, sodass das Hinzufügen oder Entfernen eines Knotens nur einen kleinen Teil der Schlüssel neu zuordnet. Rendezvous-Hashing löst dasselbe Lastverteilungsproblem mit einem einfacheren Vertrag: Für jeden Knoten der aktuellen Mitgliedschaftsmenge berechnen Sie eine Bewertung, die nur vom Schlüssel und der Identität dieses Knotens abhängt, und wählen den Knoten mit der höchsten Bewertung. Der klassische Name «highest random weight» spiegelt wider, dass der Hash wie ein pseudozufälliges Gewicht pro Paar wirkt.

Weil die Bewertung von Knoten A nie davon abhängt, ob B vorhanden ist, betrifft das Entfernen von B nur Schlüssel, für die B zuvor der Gewinner war — alle anderen bevorzugen weiterhin denselben Überlebenden. Das Hinzufügen eines Knotens C stiehlt nur jene Schlüssel, die mit C höher bewerten als mit dem bisherigen Besitzer. Diese minimale Störung ist der Grund, warum Caches, Edge-POPs und geshardete Datenbanken Rendezvous nutzen, wenn sie ausgewogenen Besitz ohne großen Virtual-Node-Ring wollen.

Dieser Endpunkt implementiert ungewichtetes HRW mit einem 32-Bit-FNV-1a-Mix aus optionalem Seed, Schlüssel und jeder Knoten-ID: der unsignierte Roh-Hash ist die Bewertung, Vergleiche sind ganzzahlig stabil. Wenn Sie positive Gewichte parallel zur Knotenliste liefern, wechselt der Algorithmus zu gewichtetem HRW: der Hash wird auf ein Einheitsintervall u in (0,1] abgebildet und die Bewertung wird u hoch eins durch das Gewicht, sodass schwerere Knoten häufiger gewinnen und alles deterministisch bleibt. Unentschieden — selten bei 32 Bit, aber möglich — werden durch die lexikografisch kleinere Knoten-ID gebrochen, damit zwei Clients nie abweichen.

Anwendungsfälle

Cache- und Shard-Affinität

Ordnen Sie Objekt- oder Benutzerschlüssel Cache-Replicas oder Datenbank-Shards zu, sodass Mitgliedschaftsänderungen nur Schlüssel umhängen, die den hinzugefügten oder entfernten Knoten bevorzugten.

Offline-Rebalance-Trockenläufe

Speisen Sie geplante Knotenlisten in denselben deterministischen Wähler in der CI, um zu messen, wie viele Schlüssel wandern würden, bevor Sie die Produktionsmitgliedschaft ändern.

Häufige Fragen

Was ist Rendezvous-Hashing (highest random weight)?

Es bewertet jedes Paar (Schlüssel, Knoten) mit einem Hash und wählt die höchste Bewertung. Es wandern nur Schlüssel, die einen entfernten Knoten bevorzugten — oder einen neu hinzugefügten bevorzugen; der Rest bleibt.

Wie wählt man einen Knoten für einen Schlüssel?

Senden Sie key und nodes (eine oder mehrere eindeutige Knoten-IDs).

Worin unterscheidet es sich vom Consistent Hashing?

Consistent Hashing platziert Schlüssel und virtuelle Knoten auf einem Ring. Rendezvous braucht weder Ring noch virtuelle Knoten: nur die lebendige Knotenliste und einen Hash aus Schlüssel plus Knoten, was Mitgliedschafts-Updates vereinfacht.

Können Knoten unterschiedliche Kapazitäten haben?

Die Methode wechselt zu gewichtetem HRW (u hoch 1/Gewicht), sodass schwerere Knoten häufiger gewinnen und deterministisch bleiben.

Was passiert mit den übrigen Schlüsseln, wenn ein Knoten wegfällt?

Sie bleiben, wo sie waren. Die Punktzahl eines Knotens hängt nur vom Schlüssel und von diesem Knoten ab, daher wandern beim Entfernen nur die Schlüssel, die er gewonnen hatte, und ein neuer Knoten übernimmt nur Schlüssel, die bei ihm höher punkten.

Für Entwickler — API-Zugang

Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.

Endpunkt

POSThttps://api.kit.forhosting.com/dev/rendezvous-hash

Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.

Aufruf aus Ihrem Stack

curl -X POST https://api.kit.forhosting.com/dev/rendezvous-hash \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"key":"user:42","nodes":["cache-a","cache-b","cache-c"]}'

const res = await fetch("https://api.kit.forhosting.com/dev/rendezvous-hash", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "key": "user:42",
    "nodes": [
      "cache-a",
      "cache-b",
      "cache-c"
    ]
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev/rendezvous-hash",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "key": "user:42",
    "nodes": [
        "cache-a",
        "cache-b",
        "cache-c"
    ]
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/rendezvous-hash", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"key":"user:42","nodes":["cache-a","cache-b","cache-c"]}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"key":"user:42","nodes":["cache-a","cache-b","cache-c"]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/rendezvous-hash", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Beispiel-Anfrage

{
  "key": "user:42",
  "nodes": [
    "cache-a",
    "cache-b",
    "cache-c"
  ]
}

Beispiel-Antwort

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.rendezvous_hash",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Preis

pro Anfrage$0.002

Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.

Fehler

HTTP	Code	Bedeutung
`401`	`unauthorized`	Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer).
`402`	`insufficient_balance`	Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht.
`404`	`unknown_type`	Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog.
`429`	`rate_limited`	Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Technische Hinweise

Die reine Parse-Implementierung ist im Browser und über die API deterministisch, verbraucht keine Modell-Tokens und greift nie auf das Netz zu.

Eingabevertrag, Antwortform und Validierungsregeln

Beispiel: key user:42 mit nodes cache-a, cache-b, cache-c ergibt einen einzigen ausgewählten Cache-Namen, der sich nicht ändert, bis Mitgliedschaft oder Seed wechseln. Kombinieren Sie den Wähler mit Ihren Health-Checks — übergeben Sie nur gesunde Knoten-IDs in nodes —, damit ausgefallene Hosts aus dem Bewertungswettlauf ausscheiden, ohne Sonderlogik im Hash. Senden Sie einen JSON-Body mit key (nicht leere Zeichenkette nach Trim; Alias object_key) und nodes (Array von einem bis tausend eindeutigen nicht leeren Knoten-IDs; Alias members). Optionaler seed (Alias salt) ist ein String-Salz, das dem Schlüssel vorangestellt wird, damit unabhängige Cluster denselben Geschäftsschlüssel unterschiedlich abbilden, ohne in der Bewertungstabelle zu kollidieren; lassen Sie ihn weg oder übergeben Sie eine leere Zeichenkette, wenn kein Salz nötig ist. Optionales weights ist ein Array positiver endlicher Zahlen derselben Länge wie nodes; lassen Sie es weg für Rendezvous mit gleichem Gewicht. Leere Schlüssel, leere Knotenlisten, Null-Einträge, doppelte Knoten-IDs, nicht positive Gewichte oder eine weights-Länge, die nicht zu nodes passt, schlagen mit invalid_input fehl und werden nicht berechnet. Bei Erfolg spiegelt die Antwort key und seed, nennt den gewählten Knoten, meldet node_count, setzt method auf rendezvous_hrw oder weighted_rendezvous_hrw und liefert scores: ein Array von Objekten mit node, weight, score und dem zugrunde liegenden Hash-Integer, sortiert nach absteigendem score und dann aufsteigendem Knotennamen. Diese vollständige Tabelle ist beabsichtigt: Lasttests und Code-Reviews müssen oft belegen, warum ein Schlüssel auf einem bestimmten Host landete.

Wo ein Rendezvous-Knotenwähler seinen Nutzen bringt

Anwendungsentwickler nutzen einen Rendezvous-Hashing-Knotenwähler, um Benutzersitzungen, Objekt-Shards oder Rate-Limit-Zähler an ein stabiles Backend zu binden, ohne ZooKeeper-Ringe oder große Consistent-Hash-Bibliotheken aufzubauen. CDN- und Multi-Region-Edge-Teams mappen Content-Schlüssel auf POPs, damit Cache-Affinität den Scale-out übersteht. Spiele- und IoT-Flotten leiten Geräte-IDs an Simulations-Worker und remeshen nur den Anteil der Geräte, der einen ausgeschiedenen Knoten bevorzugte. Datenpipelines, die Kafka-ähnliche Schlüssel über Consumer partitionieren, können Mitgliedschaftsänderungen offline durchspielen, indem sie Kandidatenlisten in dieselbe reine Funktion speisen, die die Worker aufrufen. Content-Seiten, die für Rendezvous-Hashing oder highest random weight ranking wollen, profitieren von einem kostenlosen Browser-Tool, dessen Antworten bytegleich mit der bezahlten API übereinstimmen. Weil die Implementierung reines Parse-Tier A ist, kostet jeder erfolgreiche Aufruf den veröffentlichten Basispreis $0.002 ohne Modell-Tokens und ohne ausgehendes Netz; fehlgeschlagene Validierung wird nicht berechnet.

Integrationsbeispiele

Multi-Region-Edge-Routing

Wählen Sie für jeden Content-Schlüssel einen POP oder Worker aus einer lebendigen, gesunden Liste und nutzen Sie optionale Gewichte bei ungleicher Kapazität zwischen Regionen.

Technische Fragen

Was kostet der Rendezvous-Hashing-Knotenwähler?

Das Browser-Tool ist kostenlos. API-Anfragen nutzen das vorausbezahlte KIT-Guthaben zu $0.002 pro erfolgreichem Aufruf; ungültige Eingaben werden nicht berechnet.

Vollständige KIT-Dokumentation lesen →