Redis Cluster

​

Por qué un layout aparte

• un script, un MULTI o un comando con varias claves solo puede tocar claves de un slot; si no, el servidor responde CROSSSLOT;
• KEYS y SCAN solo ven un nodo, así que un listado basado en ellos queda incompleto sin avisar.

​

Configuración

import { createCluster } from 'redis'
import { Bot } from '@botmesh/core'
import { RedisStore, RedisDurability } from '@botmesh/redis-store'

const cluster = createCluster({ rootNodes: [{ url: 'redis://redis-0:6379' }], useReplicas: false })
cluster.on('error', (err) => logger.error({ err }, 'redis cluster'))
await cluster.connect()

const store = new RedisStore({ client: cluster, prefix: 'mybot' })   // elige el layout 'cluster' solo
const bot = new Bot({
  provider,
  store,
  coordination: { coordinator: store.coordinator() },              // mismo cliente y layout
  scheduler: { store: store.schedules(), lease: store.leases() },
  durability: { backend: new RedisDurability({ client: cluster, prefix: 'mybot' }), instanceId: process.env.HOSTNAME },
})

const store = new RedisStore({
  cluster: {
    rootNodes: ['redis://redis-0:6379', 'redis://redis-1:6379'],
    // Si el cluster anuncia direcciones que tu proceso no alcanza (Docker, NAT):
    nodeAddressMap: (address) => ({ host: 'localhost', port: Number(address.split(':').pop()) }),
    defaults: { password: process.env.REDIS_PASSWORD },
  },
  prefix: 'mybot',
})

• layout: 'legacy' con un cliente cluster lanza RangeError.
• En el layout cluster el prefijo no puede llevar { ni } (rompería los hash tags).
• layout: 'cluster' también funciona en un solo nodo: así se migra un keyspace existente en el sitio, y así puedes probar el layout en local.
• store.coordinator(), store.schedules() y store.leases() heredan el layout del store. Usa el mismo layout y prefijo en todas las réplicas.
• Cambia todas las réplicas a la vez. Réplicas con layouts distintos sobre un mismo prefijo ven keyspaces distintos, y sus turnos y locks dejan de excluirse entre sí. Un RedisStore con layout legacy cuyo prefijo lleva el marcador de layout avisa en start() (logger.warn, o si no logger.error); aun así arranca.

​

Layout de claves

​

Qué cambia por dentro

• Cada script declara todas sus claves (el store comprueba que comparten slot antes de la llamada). El layout cluster usa scripts en lugar de MULTI.
• deleteChat borra los mensajes en tandas de 1000, cada tanda atómica: un item solo se va junto con su entrada del log. El registro del chat va al final. Un mensaje guardado durante el borrado sobrevive intacto. Ya no es un único script, porque el log y el registro viven en slots distintos.
• Los índices de checkpoints y de datos de usuario llevan como score la caducidad del servidor y se podan al leer, así que las entradas caducadas desaparecen de los listados igual que las claves caducadas.
• Un coordinador que espera turno no puede leer desde su script el heartbeat de otra réplica (otro slot). El script del turno informa del titular anterior, y el coordinador consulta su heartbeat con una llamada aparte de una sola clave antes de saltar su ticket. La exclusión mutua sigue basándose en la comprobación atómica de la clave owner en el slot del chat.
• Las respuestas TRYAGAIN y CLUSTERDOWN, y una redirección MOVED/ASK que node-redis no siguió, se reintentan con backoff (10 intentos, unos 2,5 s; se ajusta con withClusterRetry(client, { attempts, baseMs }) pasando el cliente envuelto). Esas respuestas llegan antes de que se ejecute nada. Una respuesta perdida nunca se reintenta.

​

Notas sobre node-redis 4

• cluster.eval(script, { keys }) se enruta por el argumento equivocado, así que puede caer en un master al azar y no seguir nunca el MOVED. Los componentes envían el EVAL enrutado por su primera clave.
• Tras un cambio de topología, un MULTI puede fallar con EXECABORT sin que node-redis vuelva a leer la topología. El layout cluster no usa MULTI.

​

Migrar un keyspace existente

1. Para todos los bots del prefijo. El helper se niega mientras exista un heartbeat de coordinador o un ticket pendiente en el origen, o en un destino distinto, salvo con allowLive: true.
2. Copia el keyspace:
   import { createClient } from 'redis'
   import { migrateToClusterLayout, inspectKeyspace } from '@botmesh/redis-store'
   
   const source = createClient({ url: 'redis://viejo:6379' })
   await source.connect()
   console.log(await inspectKeyspace({ client: source, prefix: 'mybot' }))   // conteos por layout
   const report = await migrateToClusterLayout({ source, prefix: 'mybot', dryRun: true })
   await migrateToClusterLayout({ source, prefix: 'mybot' })                 // en el sitio, o bien:
   await migrateToClusterLayout({ source, target: cluster, prefix: 'mybot' }) // directo a un cluster
   
3. Arranca los bots con el layout cluster (layout: 'cluster' en el nodo único, o un cliente cluster). Tras una migración en el sitio puedes mover los datos al cluster con tus herramientas habituales.
4. Cuando lo hayas verificado, borra las claves de origen con migrateToClusterLayout({ source, prefix, deleteSource: true }).

• Mensajes: se leen desde el log de cada chat (nunca interpretando claves de item). Los items que no pertenecen a su chat se saltan, y los que ningún log referencia se listan en report.orphans.
• Checkpoints y datos de usuario conservan el TTL que les quedaba.
• Fences de locks y terms de liderazgo se suben con “fijar si es mayor”, así que nunca retroceden. Los contadores de turno son efímeros y no se copian.
• Schedules, incluidos los marcadores de borrado, conservan su token de fencing, que nunca retrocede: un registro de origen con un token mayor reemplaza al del destino aunque no pases overwrite, y un registro sobrescrito conserva el token mayor.
• Conversaciones, cursores, leases y el journal de durabilidad conservan su nombre. Solo se copian si el destino es otro servidor u otro prefijo.
• Idempotente y reanudable: una clave de destino que ya existe gana, salvo con overwrite: true. El marcador de layout se escribe al final, y solo en una pasada completa: una pasada limitada con include no lo escribe (report.layoutMarker dice qué pasó), así que la comprobación de start() de abajo sigue activa hasta copiar todos los namespaces.

​

Vuelta atrás

​

Límites

• Replicación asíncrona. Igual que con Sentinel, un failover puede perder las últimas escrituras confirmadas: un lease concedido dos veces, una actualización compare-and-set perdida, un fence o un term repetidos. No es Redlock. Configura min-replicas-to-write 1 y apóyate en la idempotencia del outbox durable para los envíos.
• Cada tabla de durabilidad vive en un slot ({durable:<tabla>}), como antes.
• Movimiento de slots: los listados siguen siendo exactos. Las escrituras de varias claves sobre un slot en movimiento reciben TRYAGAIN y se reintentan hasta que termina el movimiento.
• Se lee solo de los masters (useReplicas: false): los bucles compare-and-set y los checkpoints tienen que ver sus propias escrituras.

​

Probar en local

docker run -d --name botmesh-it-redis-cluster -e IP=0.0.0.0 -e INITIAL_PORT=47100 \
  -e MASTERS=3 -e SLAVES_PER_MASTER=1 -p 127.0.0.1:47100-47105:47100-47105 grokzen/redis-cluster:7.0.10
BOTWA_TEST_REDIS_CLUSTER_URL=redis://127.0.0.1:47100 pnpm --filter @botmesh/redis-store test
# opcional: failover y migración de slots bajo carga
BOTWA_TEST_REDIS_CLUSTER_CHAOS=1 BOTWA_TEST_REDIS_CLUSTER_URL=redis://127.0.0.1:47100 pnpm --filter @botmesh/redis-store test
docker rm -f botmesh-it-redis-cluster