Entrevista de diseño de sistemas: Diseñar consistent hashing con nodos virtuales

Problema y escenarios aplicables

Un almacén clave-valor distribuido se ejecuta en tres zonas de disponibilidad. Cuenta con 120 nodos físicos, 24 TiB de datos lógicos, tres réplicas y dos millones de búsquedas de ubicación de claves por segundo. Un cliente o proxy de almacenamiento debe encontrar el primario y dos réplicas localmente; la ruta de la solicitud no puede contactar a un servicio central para cada búsqueda. Los nodos se unen y salen debido al escalado, mantenimiento y fallas. Un cambio de membresía debería mover únicamente las claves afectadas en lugar de causar un cold start casi completo de la caché o una migración masiva de datos.

El alcance es la capa de ubicación desde key hacia los nodos físicos y la transición segura de pertenencia cuando cambia la membresía. La consistencia de lectura/escritura, la resolución de conflictos, el motor de disco y la replicación entre regiones están fuera del diseño principal, pero una respuesta sólida debe señalar que el consistent hashing no los proporciona. Asuma un hash de 64 bits estable y bien distribuido. El tamaño de los datos, el rendimiento (throughput) y los SLO son suposiciones de entrevista, no la escala reportada de ninguna empresa.

El material actual de entrevistas de diseño de sistemas en inglés y chino de 2026 cubre explícitamente consistent hashing, nodos virtuales y escalado. El artículo de Amazon Dynamo proporciona un ejemplo de fuente primaria de consistent hashing para la partición y la ubicación de réplicas. Esta pregunta es adecuada para roles senior de backend, infraestructura y sistemas distribuidos porque convierte "mover menos datos" en una regla de pertenencia demostrable, una vista de membresía versionada y un protocolo de migración verificable.

Qué está evaluando el entrevistador

Primero, ¿puede el candidato explicar por qué hash(key) % N falla cuando N cambia en lugar de simplemente dibujar un círculo? Una respuesta sólida deduce la tasa de remapeo y distingue las particiones lógicas fijas de calcular el módulo sobre los nodos activos.

Segundo, ¿puede el candidato separar la cantidad equilibrada de claves de la carga equilibrada de solicitudes? Los nodos virtuales distribuyen muchos rangos pequeños entre los nodos físicos y pueden aproximar los pesos de capacidad. Una única clave extremadamente caliente (hot key) todavía tiene un solo propietario primario; agregar nodos virtuales no divide esa clave.

Tercero, ¿puede el candidato separar el plano de datos del plano de control? El plano de datos debe realizar búsquedas contra una instantánea (snapshot) del anillo local e inmutable. El plano de control gestiona la identidad del nodo, el estado de salud, el peso, la versión de la instantánea y el estado de migración. Si cada cliente elimina inmediatamente un nodo basándose en su propio health check, la misma clave puede adquirir propietarios en conflicto.

Cuarto, ¿entiende el candidato que el consistent hashing solo proporciona ubicación? La diversidad de réplicas, la copia completa de datos, la recuperación ante fallas y la eliminación segura requieren protocolos adicionales. "Avanzar en el sentido de las agujas del reloj hacia tres nodos" no es un diseño de disponibilidad completo.

Finalmente, ¿puede el candidato comparar particiones lógicas fijas, rendezvous hashing y jump consistent hash, y luego validar la elección frente a la distribución real de claves, la inestabilidad de membresía (membership flapping) y las instantáneas divergentes? Un número memorizado de nodos virtuales no sustituye a la evidencia.

Preguntas aclaratorias antes de responder

• ¿Se trata de una caché o de almacenamiento duradero? Una caché puede rellenarse después del escalado. Los datos duraderos deben copiarse y ponerse al día antes

de que cambie la pertenencia.

• ¿Pueden unirse y salir miembros arbitrarios, o los buckets numerados solo crecen al final? La membresía arbitraria se adapta a un anillo o a

rendezvous hashing. Los buckets secuenciales que principalmente se agregan al final hacen que valga la pena evaluar jump consistent hash.

• ¿La carga se mide por cantidad de claves, bytes o QPS? Cantidades iguales de claves no implican igual capacidad o tráfico. Las métricas de ponderación y

reequilibrio deben coincidir con el cuello de botella real.

• ¿Los nodos tienen la misma capacidad? Los nodos heterogéneos necesitan pesos. El conteo de tokens solo aproxima los pesos, por lo que una simulación con semilla fija

y métricas de producción deben verificar la proporción alcanzada.

• ¿Qué reglas de dominio de fallas aplican a las réplicas? Tres copias en una misma zona de disponibilidad fallan juntas. La selección de réplicas

debe omitir el mismo nodo físico y exigir diversidad de zonas.

• ¿Cuánto tiempo puede tomar la migración? Una transición sin tiempo de inactividad necesita versiones de instantáneas, una copia masiva, puesta al día incremental y un

breve período de lecturas dobles o reenvío. Un cold start permite una ruta más simple.

• ¿Quién publica la membresía? Los clientes necesitan una instantánea autoritativa con una época (epoch) y una suma de verificación (checksum). La inferencia de membresía

independiente genera una pertenencia dividida (split ownership).

• ¿Son importantes los escaneos de rangos (range scans)? El hashing destruye la localidad de las claves de negocio. Las cargas de trabajo con muchos rangos pueden necesitar primero particionamiento por rangos o

una capa de particiones lógicas fijas.

Estructura de respuesta en 30 segundos

"No calcularía el módulo sobre 120 nodos activos. Cuando el clúster crece a 121 nodos, hashes uniformes e IDs de buckets estables implican que alrededor del 120/121 de las claves cambian de bucket. Ubicaría las claves y los tokens de nodos virtuales en un espacio de hash fijo de 64 bits; el primer token en el sentido de las agujas del reloj es dueño de la clave. Una tabla de tokens ordenada admite búsqueda binaria, por lo que una búsqueda es O(log V). Cada nodo físico posee muchos rangos pequeños, y los nodos más grandes reciben más tokens. La selección de réplicas continúa en el sentido de las agujas del reloj pero omite nodos físicos duplicados y exige diversidad de zonas de disponibilidad. El plano de control publica instantáneas del anillo inmutables y versionadas por épocas. El almacenamiento duradero cambia la pertenencia solo después de que se completan la copia y la puesta al día. Validaría el movimiento, la variación de carga, los pesos y los dominios de fallas con una simulación de semilla fija, y manejaría las hot-keys por separado porque los nodos virtuales no resuelven el sesgo de una sola clave."

Análisis detallado paso a paso

Paso 1: Cuantificar el costo de remapeo del hashing por módulo

El mapeo directo es:

owner = nodes[hash(key) % N]

Cuando los IDs de buckets estables crecen de N a N + 1, una clave conserva su bucket numérico solo si hash % N = hash % (N + 1). Los enteros consecutivos son coprimos. A lo largo de un ciclo completo de residuos de N × (N + 1), exactamente N valores de hash satisfacen esa igualdad. La fracción retenida es, por tanto, 1 / (N + 1), y la fracción remapeada es N / (N + 1).

Hacer crecer este clúster de 120 a 121 nodos cambia el propietario esperado de aproximadamente el 120/121 = 99.17% de las claves. Cerca de 23.8 TiB del conjunto de datos lógicos de 24 TiB recibe una nueva ubicación. Puede que una caché no copie físicamente esos bytes, pero aun así experimenta un evento de cold miss casi total. Esta deducción asume hashes uniformes, IDs de buckets estables y un módulo sobre el conteo de nodos activos. Si las claves primero se mapean a un número fijo de particiones lógicas, y el plano de control mueve solo las particiones seleccionadas, la membresía activa ya no altera la primera fórmula de mapeo.

Paso 2: Definir el anillo, los tokens y la búsqueda local

Elija una función de hash de 64 bits y una codificación fijas. Mapee tanto las claves como los tokens de nodos virtuales en ese espacio. Ordene los tokens como valores sin signo y cierre el ciclo desde el valor máximo hasta cero. El primer token en el sentido de las agujas del reloj es dueño de la clave; una búsqueda binaria que sobrepasa el final del arreglo devuelve el primer token.

locate(key, snapshot):
  h = stableHash64(key)
  i = lowerBound(snapshot.sortedTokens, h)
  if i == snapshot.sortedTokens.length:
    i = 0
  return snapshot.sortedTokens[i].physicalNodeId

Con V tokens en total, la búsqueda cuesta O(log V) y la instantánea utiliza O(V) de memoria. Las colisiones de tokens necesitan un ordenamiento determinista como (token, physicalNodeId, vnodeIndex); el orden de sobreescritura de un mapa no es un protocolo. Utilice un UUID persistente o un identificador de despliegue estable para un nodo. Usar una dirección IP efímera provoca un cambio de membresía innecesario cada vez que un nodo reiniciado recibe una nueva dirección.

Bajo un equilibrio ideal, el nodo número 121 de igual capacidad recibe aproximadamente el 1/121 de las claves. Para 24 TiB de datos lógicos, el movimiento esperado es de 24/121 TiB ≈ 203 GiB, obtenido a partir de muchos rangos pequeños que adquiere el nuevo nodo. Esta es una expectativa para la planificación de capacidad, no un límite estricto. Cantidades finitas de tokens, la variación del tamaño de los valores y el sesgo de acceso pueden alejar el resultado observado de los 203 GiB.

Paso 3: Utilizar nodos virtuales para el equilibrio de rangos y pesos de capacidad

Con un token por nodo físico, los intervalos aleatorios pueden diferir enormemente y un nodo saliente transfiere todo su rango a un solo sucesor. Los nodos virtuales otorgan a cada nodo físico muchos tokens dispersos, dividiendo un rango grande en unidades de migración más pequeñas. Un nodo físico con fallas transfiere entonces sus rangos a varios sucesores en lugar de sobrecargar una sola máquina.

No copie un recuento universal de tokens de una guía de entrevistas. Reproduzca distribuciones reales o representativas de claves, tamaños de valores y QPS mientras incrementa los tokens por nodo. Mida:

key_count_share, byte_share, qps_share
max_load / mean_load
coefficient_of_variation
snapshot_bytes and lookup_latency

Deténgase cuando los tokens adicionales aporten poca ganancia de equilibrio y los costos de instantáneas, actualizaciones y búsqueda binaria permanezcan dentro del presupuesto. Para capacidades heterogéneas, haga que el conteo objetivo de tokens de un nodo sea aproximadamente proporcional a su peso; los tokens aleatorios aún producen una aproximación estadística. Cuando el sistema requiere pesos exactos, la asignación explícita de particiones lógicas fijas suele ser más fácil de operar.

Los nodos virtuales suavizan la pertenencia agregada de rangos. Una clave responsable del 20% de las solicitudes aún se mapea a un único primario. Manéjela con réplicas de lectura, coalescencia de solicitudes (request coalescing), una near cache, división de claves consciente del negocio (key splitting) o límites de tasa (rate limits). Incrementar los nodos virtuales de 100 a 1,000 no cambia ese hecho.

Paso 4: Diseñar la selección de réplicas y el modelo de instantáneas

Después de encontrar el primario, continúe en el sentido de las agujas del reloj y recopile nodos físicos distintos hasta obtener tres réplicas. Omita otro token virtual que pertenezca a un nodo físico ya seleccionado. La diversidad de zonas de disponibilidad debe ser una restricción, no una propiedad afortunada de tres propietarios adyacentes.

RingSnapshot {
  epoch,
  hashAlgorithm,
  tokens: [{ token, physicalNodeId, weight, zone, state }],
  checksum,
  activatedAt
}

Placement {
  keyHash,
  epoch,
  owners: [{ physicalNodeId, zone, role }]
}

El plano de datos intercambia atómicamente instantáneas inmutables. Una solicitud registra o transporta su epoch; un servidor que observa una versión antigua puede devolver una sugerencia de versión o reenviar al propietario actual. El plano de control valida la unicidad de los nodos físicos y los dominios de fallas para cada conjunto de réplicas. Si existen muy pocos nodos saludables, reporta un estado sub-replicado (under-replicated) en lugar de seleccionar la misma máquina dos veces y fingir que tiene tres copias.

El consistent hashing propone ubicaciones pero no define la confirmación de escritura (write acknowledgment). El almacenamiento duradero aún debe decidir cuántas réplicas confirman una escritura, cómo las lecturas reconcilian versiones, cómo la reparación verifica los bytes y si una partición de red favorece la consistencia o la disponibilidad.

Paso 5: Convertir los cambios de membresía en migraciones versionadas

Una unión planificada puede utilizar esta máquina de estados:

joining -> copying -> catching_up -> active
active  -> draining -> removed

El plano de control calcula la diferencia de pertenencia respecto a la época actual. Un nodo joining no recibe tráfico primario. Un trabajo en segundo plano copia los rangos afectados desde los antiguos propietarios y los verifica por versión de clave o posición de log. Las escrituras realizadas durante la copia ingresan a un log incremental o a una ruta de doble escritura. Después de la copia masiva, el nuevo nodo se pone al día. Solo cuando se superan los controles de suma de verificación y salud de réplicas, el plano de control publica una nueva época y cambia el enrutamiento atómicamente. Los propietarios anteriores retienen los datos durante un período de gracia limitado para atender solicitudes con instantáneas obsoletas y respaldar rollbacks, y luego los eliminan.

El drenado (draining) sigue el mismo orden: copiar y ponerse al día hacia los nuevos propietarios, publicar una instantánea sin el nodo, detenerlo y finalmente reclamar los rangos antiguos. La matemática del anillo identifica los rangos afectados; no reemplaza la copia, la limitación de velocidad (throttling), la verificación ni el rollback. El worker de migración también limita los bytes concurrentes para que un movimiento esperado de 203 GiB no consuma el presupuesto de lectura/escritura en primer plano.

Paso 6: Separar el manejo de fallas del acuerdo de membresía

Cuando un nodo falla abruptamente, el sistema no puede copiar desde él primero. El plano de datos atiende desde las réplicas existentes mientras un worker de reparación reconstruye las réplicas faltantes en nodos saludables de acuerdo con la época de membresía autoritativa. Un tiempo de espera breve no debería reescribir inmediatamente el anillo, o el flapping provocará migraciones repetidas. Un gestor de salud utiliza fallas consecutivas, leases o acuerdos del plano de control para marcar un nodo como no disponible y distingue el reenvío temporal de la eliminación permanente.

Todos los clientes deben observar una única secuencia de membresía versionada. Si el cliente A elimina el nodo X mientras el cliente B aún trata a X como el primario, la misma clave puede recibir escrituras en diferentes ubicaciones. Un plano de control respaldado por consenso puede mantener la configuración del anillo y distribuir instantáneas con épocas y sumas de verificación. Durante ventanas cortas de sesgo de versiones, los clientes utilizan reenvío del servidor, lecturas dobles o un protocolo explícito de reintentos. "Todos eventualmente reciben la configuración" no es, por sí mismo, un mecanismo de corrección.

Si el plano de control no está disponible, el plano de datos continúa con su última instantánea verificada. El tiempo durante el cual las lecturas y escrituras pueden continuar depende de la consistencia de réplicas y del modelo de fallas. Los nodos individuales no deben reescribir permanentemente el anillo mientras la vista autoritativa de membresía no esté disponible.

Paso 7: Comparar alternativas bajo las restricciones reales

Si cualquier nodo sin estado puede procesar cualquier solicitud, el balanceo de carga ordinario es más simple. El consistent hashing es valioso cuando una clave debe preservar un propietario. Si la carga de trabajo está dominada por escaneos de rangos, destruir el orden de las claves puede costar más de lo que ahorra el movimiento reducido. Elija primero la abstracción de ubicación y el algoritmo en segundo lugar.

Paso 8: Validar propiedades, carga y comportamiento ante fallas

Una prueba offline fija el algoritmo de hash y la semilla, genera millones de claves sintéticas, guarda una instantánea base y luego ejecuta uniones, drenados y fallas:

1. Medir moved_keys / total_keys y demostrar que las claves fuera de los rangos con diferencia de pertenencia no se mueven.
2. Calcular max/mean y el coeficiente de variación por recuento de claves, bytes y QPS, no solo un histograma de claves.
3. Asignar pesos 1:2:4, verificar que las proporciones a largo plazo se aproximen a los objetivos y registrar los rendimientos decrecientes al añadir más tokens.
4. Comprobar que las tres réplicas de cada clave utilicen nodos físicos distintos y las tres zonas de disponibilidad.
5. Ejecutar dos épocas concurrentemente, descartar instantáneas y corromper sumas de verificación para probar el reenvío, los reintentos y la expulsión de versiones antiguas.
6. Apagar nodos antiguos y nuevos a mitad de la copia y confirmar que una migración incompleta nunca elimine la única copia saludable.
7. Inyectar una hot key e inestabilidad repetida de membresía para verificar la protección contra hotspots y la eliminación de rebotes de membresía (debouncing) de forma independiente.

El monitoreo de producción incluye la adopción por época, el sesgo de claves/bytes/QPS, el backlog y la velocidad de migración, las solicitudes con versiones antiguas, la tasa de reenvío, los rangos sub-replicados, las hot keys y la latencia del cálculo de hash. Una operación de escalado está completa cuando estas señales son satisfactorias, no simplemente cuando el nuevo nodo aparece en el anillo.

Respuesta de ejemplo sólida

"En primer lugar, mantendría el alcance acotado a la ubicación de claves. Con un módulo sobre 120 nodos activos, crecer a 121 cambia el bucket para cerca del 120/121 de las claves, lo que equivale casi a un remapeo completo de 24 TiB. Las particiones lógicas fijas podrían evitar ese problema. Si elijo consistent hashing, coloco las claves y los tokens de nodo en un espacio fijo de 64 bits y asigno cada clave al primer token en el sentido de las agujas del reloj. Los clientes mantienen una instantánea inmutable ordenada y utilizan búsqueda binaria, por lo que la ruta crítica no tiene llamadas centrales y cuesta O(log V).

Cada nodo físico recibe múltiples tokens virtuales para distribuir los rangos y el movimiento por fallas. Los nodos heterogéneos reciben diferentes objetivos de tokens según su capacidad. No declararía 100 tokens por nodo sin evidencia; reproduciría tamaños reales de clave y QPS y compararía la carga máxima respecto a la media, el coeficiente de variación, el tamaño de la instantánea y la latencia de búsqueda. Los nodos virtuales suavizan los rangos, mientras que una sola hot key aún necesita réplicas de lectura, coalescencia de solicitudes, división de claves o límites de tasa.

La ubicación de réplicas recorre el anillo en el sentido de las agujas del reloj hacia tres nodos físicos distintos y exige las tres zonas de disponibilidad. Un plano de control respaldado por consenso publica instantáneas del anillo con épocas y sumas de verificación. Para un escalado horizontal planificado, el nuevo nodo primero copia sus rangos y se pone al día con las escrituras incrementales. Una nueva época se vuelve activa solo después de la verificación; los antiguos propietarios eliminan los datos tras un período de gracia. Una falla abrupta atiende desde las réplicas saludables y las reconstruye, porque dibujar el anillo no es un protocolo de recuperación.

Finalmente, usaría millones de claves con semilla fija para probar el movimiento, el sesgo por claves/bytes/QPS, los pesos y los dominios de réplicas, para luego inyectar épocas duales, migraciones interrumpidas, flapping de membresía y una hot key. Si los objetivos son buckets secuenciales, compararía jump hash. Si el movimiento preciso y controlado por el operador importa más, preferiría particiones lógicas fijas."

Errores comunes

• Solo dibujar un anillo → la respuesta nunca explica por qué falla el módulo ni cuánto se mueve → **deduzca la tasa de remapeo y

aplíquela al conjunto de datos.**

• Un solo punto por nodo físico → los intervalos aleatorios sesgan los rangos y un único sucesor absorbe la falla → **utilice múltiples tokens y

elija la cantidad mediante reproducción de carga.**

• Tratar los nodos virtuales como una solución a las hot-keys → una sola clave sigue teniendo un único primario → **utilice réplicas, coalescencia de solicitudes, división

de claves o límites de tasa.**

• Tomar los siguientes tres tokens como tres réplicas → pueden pertenecer a la misma máquina o zona → **desduplique los nodos físicos

y aplique restricciones de dominio de fallas.**

• Enrutar hacia un nodo recién incorporado de inmediato → los datos duraderos aún no han llegado → **copie, póngase al día, verifique, publique la época

y solo entonces elimine las copias antiguas.**

• Permitir que los clientes expulsen nodos caídos independientemente → una membresía divergente genera pertenencia dividida → **publique instantáneas

versionadas desde un plano de control autoritativo.**

• Afirmar que una incorporación mueve exactamente el 1/N → tokens y pesos finitos hacen que los rangos sean desiguales → **formúlelo como una expectativa bajo

supuestos de equilibrio y mida la distribución real.**

• Fijar rígidamente "200 vnodes por nodo" → ignora el tamaño del valor, QPS, tamaño de instantánea y costo de búsqueda → **reproduzca la carga de trabajo y

encuentre el punto de rendimientos decrecientes.**

• Ignorar la versión del algoritmo de hash → las diferencias de codificación o implementación remapean cada clave → **incluya el algoritmo,

la codificación, la época y la suma de verificación en la instantánea.**

• Usar consistent hashing para todo problema de sharding → las consultas de rango u operaciones precisas pueden favorecer otro enfoque →

compare particiones fijas, rendezvous y jump hash.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Por qué agregar un nodo al anillo no mueve exactamente el 1/(N+1) de las claves?

Esa fracción asume claves y nodos distribuidos uniformemente, igual capacidad y suficientes tokens. Un conjunto finito de tokens aleatorios crea intervalos desiguales, mientras que los tamaños de valores y las QPS también pueden sesgarse. Es una expectativa. Reproduzca claves, bytes y tráfico reales antes del lanzamiento y reserve ancho de banda de migración por encima del valor esperado. Si cada operación necesita una unidad de movimiento precisamente delimitada, las particiones lógicas fijas son una mejor opción.

Pregunta de seguimiento 2: ¿Por qué sigue siendo necesario un plano de control de membresía cuando las réplicas abarcan tres zonas?

La ubicación de réplicas tiene sentido únicamente cuando los participantes coinciden en una época. Dos clientes con anillos diferentes pueden enviar nuevas escrituras a diferentes conjuntos de réplicas, y cada uno puede creer que logró tres copias. El plano de control linealiza los cambios de membresía y publica versiones. Durante el sesgo de versiones, el reenvío, las lecturas dobles o el rechazo de escrituras obsoletas impulsan la convergencia. La diversidad de dominios de fallas no reemplaza el ordenamiento de la membresía.

Pregunta de seguimiento 3: Un inquilino produce el 40% de las QPS a través de una sola clave. ¿Ayudan más vnodes?

No. Los nodos virtuales cambian cómo se distribuyen los rangos; no asignan un único valor de hash a múltiples primarios. Una clave con muchas lecturas puede usar múltiples réplicas de lectura y coalescencia de solicitudes. Una clave con muchas escrituras necesita una división consciente del negocio, estado fusionable particionado o límites de tasa para el inquilino. Si las escrituras deben serializarse, el requisito de consistencia de clave única es el límite de throughput y debe declararse explícitamente.

Pregunta de seguimiento 4: Las escrituras continúan durante la copia por escalado horizontal. ¿Cómo se evita perder los cambios incrementales?

La copia registra una posición de log o marca de agua (watermark) de versión. Primero copia el rango hasta esa marca de agua, y luego consume los cambios posteriores; una breve ventana de doble escritura es otra opción. La nueva época se publica solo después de que el nuevo nodo alcanza la marca de agua de transición, la verificación es exitosa y las réplicas están saludables. Los propietarios anteriores mantienen un período de gracia para solicitudes tardías y confirman que no haya rangos sub-replicados antes de la eliminación.

Pregunta de seguimiento 5: ¿Pueden continuar las lecturas y escrituras cuando el plano de control está caído?

El plano de datos sigue utilizando la última instantánea inmutable con una suma de verificación válida, por lo que las búsquedas individuales continúan. Las escrituras seguras después de la falla de un nodo dependen de las réplicas restantes y de la regla de consistencia de escritura; los clientes no pueden cambiar permanentemente el anillo por su cuenta. Exponga la antigüedad de la instantánea y degrade o detenga las escrituras cuando se supere la ventana de seguridad o el recuento requerido de réplicas. Que las lecturas continúen no demuestra que las escrituras sean seguras.

Pregunta de seguimiento 6: ¿Cuándo seleccionaría jump consistent hash?

Elíjalo para buckets lógicos numerados secuencialmente que crecen principalmente al final cuando importa un mapeo rápido con memoria constante. La eliminación arbitraria y los nodos físicos con identidad son complejos, por lo que un sistema a menudo mapea claves a buckets lógicos primero y deja que el plano de control ubique los buckets en las máquinas. Esa indirección también permite que el almacenamiento mueva buckets sin cambiar el algoritmo de clave a bucket.

Pregunta de seguimiento 7: ¿Cómo se puede actualizar la función de hash sin causar un enrutamiento incorrecto para todo el conjunto de datos?

El nombre de la función, la semilla y la codificación de las claves son parte del protocolo de instantáneas. Cree una nueva época, calcule la diferencia de pertenencia de la versión anterior a la nueva fuera de línea, luego copie y ponga al día los datos mediante el proceso normal de migración. Durante la transición, las solicitudes transportan la versión del algoritmo y los servidores pueden reenviar a los nuevos propietarios. Permitir que solo algunos clientes adopten la función genera una pertenencia dividida casi total, por lo que la actualización debe manejarse como una repartición completa controlada.