Selector de nodo por hash de rendezvous
Asigne una clave a un nodo de su lista: user:42 entre cache-a, cache-b y cache-c cae en cache-a, y ahí se queda mientras no cambien los nodos ni la semilla. Verá la puntuación de cada nodo para auditar la elección. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- Key
- user:42
- Nodos
- cache-a, cache-b, cache-c
- Semilla
- Seleccionado
- cache-a
- Número de nodos
- 3
El hash de rendezvous, también llamado highest random weight hashing, asigna cada clave a exactamente un nodo del conjunto activo sin anillo de nodos virtuales. Para cada nodo candidato el algoritmo combina la clave con el identificador del nodo, ordena las puntuaciones y elige al ganador. Cuando un nodo entra o sale, solo se mueven las claves que preferían al nodo saliente o que ahora prefieren al recién llegado; el resto permanece, de modo que la tasa de aciertos de caché y la propiedad de shards se mantienen estables ante cambios de membresía. Este selector acepta una clave de enrutado, una lista de ids de nodo, una semilla de clúster opcional y pesos positivos opcionales, y devuelve el nodo elegido más la tabla completa de puntuaciones para auditar o probar el emplazamiento.
Cómo el hash de rendezvous elige un nodo para una clave
El consistent hashing popularizó colocar claves en un anillo para que añadir o quitar un nodo reubique solo una fracción de las claves. El hash de rendezvous resuelve el mismo equilibrio de carga con un contrato más simple: para cada nodo del conjunto de membresía actual se calcula una puntuación que depende solo de la clave y de la identidad de ese nodo, y se selecciona el de mayor puntuación. El nombre clásico «highest random weight» refleja que el hash se comporta como un peso seudoaleatorio por par.
Como la puntuación del nodo A no depende de si B está presente, quitar B solo afecta a las claves para las que B era el ganador; el resto sigue prefiriendo al mismo superviviente. Añadir un nodo C solo se lleva las claves que puntúan más alto con C que con su dueño anterior. Esa disrupción mínima es por lo que cachés, POP de borde y bases de datos fragmentadas usan rendezvous cuando desean propiedad equilibrada sin un anillo grande de nodos virtuales.
Si usted aporta pesos positivos paralelos a la lista de nodos, el algoritmo pasa a HRW ponderado: el hash se proyecta a un intervalo unitario u en (0,1] y la puntuación es u elevado a uno entre el peso, de modo que los nodos más pesados ganan más a menudo y todo sigue siendo determinista. Los empates —raros con 32 bits pero posibles— se deshacen eligiendo el id de nodo lexicográficamente menor para que dos clientes no discrepen.
Dónde un selector de nodo rendezvous aporta valor
Los desarrolladores de aplicaciones usan un selector de nodo por hash de rendezvous para fijar sesiones de usuario, shards de objetos o contadores de límite de tasa a un backend estable sin levantar anillos ZooKeeper ni grandes bibliotecas de consistent hashing. Los equipos de CDN y de borde multi-región mapean claves de contenido a POP para que la afinidad de caché sobreviva al escalado. Flotas de juegos e IoT enrutan ids de dispositivo a workers de simulación y solo reasignan la fracción que prefería un nodo que se fue.
Las canalizaciones de datos que particionan claves al estilo Kafka entre consumidores pueden simular offline cambios de membresía alimentando listas candidatas en la misma función pura que llamarán los workers.
Qué puede hacer con ella
Afinidad de caché y de shards
Asigne claves de objeto o de usuario a réplicas de caché o shards de base de datos de modo que un cambio de membresía solo remueva las claves que preferían el nodo añadido o eliminado.
Enrutado de borde multi-región
Elija un POP o worker de una lista viva y sana para cada clave de contenido, usando pesos opcionales cuando la capacidad no es uniforme entre regiones.
Simulaciones offline de reequilibrio
Introduzca listas planificadas de nodos en el mismo selector determinista en CI para medir cuántas claves se moverían antes de cambiar la membresía en producción.
Preguntas frecuentes
¿Qué es el hash de rendezvous (highest random weight)?
Puntúa cada par (clave, nodo) con un hash y elige la puntuación más alta. Solo se mueven las claves que preferían un nodo eliminado o que prefieren uno recién añadido; el resto permanece.
¿Cómo se selecciona un nodo para una clave?
Envíe key y nodes (uno o más ids de nodo únicos). El campo selected de la respuesta es el nodo ganador.
¿En qué se diferencia del consistent hashing?
El consistent hashing coloca claves y nodos virtuales en un anillo. Rendezvous no necesita anillo ni nodos virtuales: solo la lista viva de nodos y un hash de clave más nodo, lo que simplifica las actualizaciones de membresía.
¿Pueden los nodos tener capacidades distintas?
El método pasa a HRW ponderado (u elevado a 1/peso) para que los nodos más pesados ganen más a menudo sin dejar de ser deterministas.
¿Qué pasa con las demás claves si se retira un nodo?
Se quedan donde estaban. La puntuación de cada nodo depende solo de la clave y de ese nodo, así que retirar uno mueve únicamente las claves que ganaba, y añadir otro solo le lleva las claves que ahora puntúan más alto con él.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su 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)Ejemplo de solicitud
{
"key": "user:42",
"nodes": [
"cache-a",
"cache-b",
"cache-c"
]
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.rendezvous_hash",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
La implementación parse pura es determinista en navegador y API, no consume tokens de modelo y no usa la red.
Cómo el hash de rendezvous elige un nodo para una clave
Este endpoint implementa HRW sin pesos con una mezcla FNV-1a de 32 bits de semilla opcional, clave e id de cada nodo: el hash sin signo es la puntuación, con comparaciones estables enteras.
Contrato de entrada, forma de respuesta y reglas de validación
Esa tabla completa es intencional: los arneses de carga y las revisiones de código a menudo deben demostrar por qué una clave aterrizó en un host concreto. Combine el selector con sus comprobaciones de salud —pase solo ids sanos en nodes— para que los hosts fallidos salgan de la carrera de puntuación sin lógica especial dentro del hash. Envíe un cuerpo JSON con key (cadena no vacía tras recortar; alias object_key) y nodes (array de uno a mil ids de nodo distintos no vacíos; alias members). La seed opcional (alias salt) es una sal de cadena antepuesta a la clave para que clústeres independientes mapeen la misma clave de negocio de forma distinta sin colisionar en la tabla de puntuaciones; omítala o pase cadena vacía si no hay sal. weights opcional es un array de números finitos positivos de la misma longitud que nodes; omítalo para rendezvous de peso igual. Claves vacías, listas vacías, entradas nulas, ids duplicados, pesos no positivos o longitudes que no coinciden fallan con invalid_input y no se facturan. En éxito la respuesta repite key y seed, nombra el nodo seleccionado, informa node_count, fija method en rendezvous_hrw o weighted_rendezvous_hrw y devuelve scores: un array de objetos con node, weight, score y el entero hash subyacente, ordenado por score descendente y luego nombre de nodo ascendente. Ejemplo: key user:42 con nodes cache-a, cache-b, cache-c produce un único nombre de caché seleccionado que no cambia hasta que cambien la membresía o la seed.
Dónde un selector de nodo rendezvous aporta valor
Los sitios de contenido que compiten por «rendezvous hashing» o «highest random weight» se benefician de una herramienta gratuita en el navegador cuyas respuestas coinciden byte a byte con la API de pago. Como la implementación es parse pura de nivel A, cada llamada correcta cuesta el precio base publicado $0.002 sin tokens de modelo ni red saliente; la validación fallida no consume saldo.
Preguntas técnicas
¿Cuánto cuesta el selector de nodo por hash de rendezvous?
La herramienta del navegador es gratuita. Las peticiones API usan saldo prepago de KIT a $0.002 por llamada correcta; la entrada inválida no se factura.