Selettore di nodo con hash di rendezvous
Assegni una chiave a un nodo della sua lista: user:42 tra cache-a, cache-b e cache-c finisce su cache-a e lì resta finché non cambiano i nodi o il seme. Il punteggio di ogni nodo è visibile per verificare la scelta. Gratis nel suo browser.
- Gratis
- Funziona nel suo browser
- Senza registrazione
- I suoi dati restano sul dispositivo
Esegui gratis nel browser
Esempio risolto
- Key
- user:42
- Nodi
- cache-a, cache-b, cache-c
- Seme
- Selezionato
- cache-a
- Numero di nodi
- 3
L’hash di rendezvous, detto anche highest random weight hashing, assegna ogni chiave a esattamente un nodo dell’insieme attivo senza anello di nodi virtuali. Per ogni nodo candidato l’algoritmo combina la chiave con l’identificatore di quel nodo, ordina i punteggi e sceglie il vincitore. Quando un nodo entra o esce, si muovono solo le chiavi che preferivano il nodo uscito o che ora preferiscono il nuovo arrivato; il resto resta fermo, così il tasso di hit della cache e la proprietà degli shard restano stabili al variare dell’appartenenza. Questo selettore accetta una chiave di routing, un elenco di id di nodo, un seed opzionale di cluster e pesi positivi opzionali, e restituisce il nodo scelto più la tabella completa dei punteggi affinché Lei possa verificare o collaudare il posizionamento.
Come l’hash di rendezvous sceglie un nodo per una chiave
Il consistent hashing ha reso popolare l’idea di collocare le chiavi su un anello così che aggiungere o rimuovere un nodo rimappi solo una frazione delle chiavi. L’hash di rendezvous risolve lo stesso bilanciamento del carico con un contratto più semplice: per ogni nodo nell’insieme di appartenenza corrente si calcola un punteggio che dipende solo dalla chiave e dall’identità di quel nodo, poi si seleziona il punteggio più alto. Il nome classico «highest random weight» riflette che l’hash si comporta come un peso pseudocasuale per coppia.
Poiché il punteggio del nodo A non dipende mai dalla presenza di B, rimuovere B colpisce solo le chiavi per cui B era il vincitore; tutte le altre preferiscono ancora lo stesso superstite. Aggiungere un nodo C ruba solo le chiavi che ottengono un punteggio più alto con C che con il precedente proprietario. Quella disruzione minima spiega perché cache, POP di edge e database frammentati usano il rendezvous quando vogliono proprietà equilibrata senza mantenere un grande anello di nodi virtuali.
Quando Lei fornisce pesi positivi paralleli all’elenco dei nodi, l’algoritmo passa a HRW ponderato: l’hash è proiettato su un intervallo unitario u in (0,1] e il punteggio diventa u elevato a uno sul peso, così i nodi più pesanti vincono più spesso restando pienamente deterministici. I pareggi — rari con 32 bit ma possibili — si risolvono scegliendo l’id di nodo lessicograficamente minore affinché due client non divergano mai.
Dove un selettore di nodo rendezvous crea valore
Gli sviluppatori di applicazioni usano un selettore di nodo con hash di rendezvous per vincolare sessioni utente, shard di oggetti o contatori di rate limit a un backend stabile senza erigere anelli ZooKeeper né grandi librerie di consistent hashing. I team CDN e di edge multi-regione mappano chiavi di contenuto su POP affinché l’affinità di cache sopravviva allo scale-out. Flotte di giochi e IoT instradano id di dispositivo verso worker di simulazione e rimappano solo la frazione che preferiva un nodo uscito.
Le pipeline di dati che partizionano chiavi in stile Kafka tra consumer possono simulare offline i cambiamenti di appartenenza alimentando elenchi candidati nella stessa funzione pura che i worker chiameranno.
Casi d'uso
Affinità di cache e di shard
Mappi chiavi di oggetto o di utente su repliche di cache o shard di database così che un cambio di appartenenza sposti solo le chiavi che preferivano il nodo aggiunto o rimosso.
Routing di edge multi-regione
Scelga un POP o un worker da un elenco vivo e sano per ogni chiave di contenuto, usando pesi opzionali quando la capacità non è uniforme tra le regioni.
Simulazioni offline di ribilanciamento
Alimenti elenchi di nodi pianificati nello stesso selettore deterministico in CI per misurare quante chiavi si muoverebbero prima di cambiare l’appartenenza in produzione.
Domande frequenti
Che cos’è l’hash di rendezvous (highest random weight)?
Assegna un punteggio a ogni coppia (chiave, nodo) con un hash e sceglie il punteggio più alto. Si muovono solo le chiavi che preferivano un nodo rimosso o che preferiscono uno appena aggiunto; il resto resta fermo.
Come si seleziona un nodo per una chiave?
Invii key e nodes (uno o più id di nodo unici). Il campo selected della risposta è il nodo vincitore.
In che cosa differisce dal consistent hashing?
Il consistent hashing colloca chiavi e nodi virtuali su un anello. Il rendezvous non necessita di anello né di nodi virtuali: solo l’elenco vivo dei nodi e un hash di chiave più nodo, il che semplifica gli aggiornamenti di appartenenza.
I nodi possono avere capacità diverse?
Il metodo passa a HRW ponderato (u elevato a 1/peso) così i nodi più pesanti vincono più spesso restando deterministici.
Che cosa succede alle altre chiavi quando si rimuove un nodo?
Restano dove erano. Il punteggio di un nodo dipende solo dalla chiave e da quel nodo, quindi rimuoverne uno sposta soltanto le chiavi che vinceva, e aggiungerne uno gli assegna solo le chiavi che ora ottengono con lui un punteggio più alto.
Strumenti correlati
Per sviluppatori — accesso via API
Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.
Endpoint
Autenticazione con Bearer token: un POST mette in coda l'attività e il risultato arriva via webhook o link firmato.
Chiamala dal tuo 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)Esempio di richiesta
{
"key": "user:42",
"nodes": [
"cache-a",
"cache-b",
"cache-c"
]
}Esempio di risposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.rendezvous_hash",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.
Prezzi
Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.
Errori
| HTTP | Codice | Significato |
|---|---|---|
401 | unauthorized | Chiave API mancante o non valida: controlla l'header Authorization. |
402 | insufficient_balance | Credito esaurito: ricarica per continuare a eseguire attività. |
404 | unknown_type | Tipo di attività sconosciuto: controlla il campo type della richiesta. |
429 | rate_limited | Troppe richieste in poco tempo: rallenta e riprova tra qualche secondo. |
Note tecniche
L’implementazione parse pura è deterministica su browser e API, non consuma token di modello e non raggiunge mai la rete.
Come l’hash di rendezvous sceglie un nodo per una chiave
Questo endpoint implementa HRW non ponderato con un mix FNV-1a a 32 bit di seed opzionale, chiave e id di ogni nodo: l’hash non firmato è il punteggio, con confronti interi stabili.
Contratto di input, forma della risposta e regole di validazione
Quella tabella completa è intenzionale: i harness di carico e le revisioni del codice spesso devono dimostrare perché una chiave è atterrata su un host particolare. Abbini il selettore ai Suoi controlli di salute — passi solo id sani in nodes — così gli host guasti escono dalla corsa dei punteggi senza logica speciale dentro l’hash. Invii un corpo JSON con key (stringa non vuota dopo trim; alias object_key) e nodes (array da uno a mille id di nodo distinti non vuoti; alias members). Il seed opzionale (alias salt) è un sale di stringa prefisso alla chiave così che cluster indipendenti mappino la stessa chiave di business in modo diverso senza collidere nella tabella dei punteggi; lo ometta o passi una stringa vuota se non serve sale. weights opzionale è un array di numeri finiti positivi della stessa lunghezza di nodes; lo ometta per rendezvous a peso uguale. Chiavi vuote, elenchi vuoti, voci nulle, id duplicati, pesi non positivi o lunghezze non coincidenti falliscono con invalid_input e non sono addebitati. In caso di successo la risposta ripete key e seed, nomina il nodo selezionato, riporta node_count, imposta method su rendezvous_hrw o weighted_rendezvous_hrw e restituisce scores: un array di oggetti con node, weight, score e l’intero hash sottostante, ordinato per score decrescente e poi nome nodo crescente. Esempio: key user:42 con nodes cache-a, cache-b, cache-c produce un unico nome di cache selezionato che non cambia finché non cambiano l’appartenenza o il seed.
Dove un selettore di nodo rendezvous crea valore
I siti di contenuti che competono su «rendezvous hashing» o «highest random weight» beneficiano di uno strumento gratuito nel browser le cui risposte coincidono byte per byte con l’API a pagamento. Poiché l’implementazione è parse pura di livello A, ogni chiamata riuscita costa il prezzo base pubblicato $0.002 senza token di modello né rete in uscita; la validazione fallita non consuma saldo.
Domande tecniche
Quanto costa il selettore di nodo con hash di rendezvous?
Lo strumento nel browser è gratuito. Le richieste API usano il saldo prepagato KIT a $0.002 per chiamata riuscita; l’input non valido non viene addebitato.