menuTicketing

Despliegue del servidor Ticketing

Entorno
Modo
bash
Ejemplo de conexión de cliente
rust
Prueba rápida con nc
bash

Variables de entorno

Cada elemento de ticketing.toml (opcional) también se puede pasar como variable de entorno. La prioridad es variable de entorno > ticketing.toml > valor por defecto, y las claves y valores booleanos no distinguen mayúsculas de minúsculas. La imagen de Docker se basa en scratch, por lo que inyectar la configuración mediante variables de entorno es el método por defecto (si se quiere usar un archivo de configuración, hay que montarlo e indicar la ruta con CONFIG).

variable de entornovalor por defectodescripción
PORT (SERVER_PORT)5225Puerto TCP de escucha. Se ignora en modo clúster, donde se usa el puerto de CLUSTER_SELF
DEBUG (SERVER_DEBUG)según el build1/true activa logs de debug
SOCKET_BIND0.0.0.0Dirección de escucha
SOCKET_NODELAYtrueTCP_NODELAY
SOCKET_READ_BUF_LEN4096Búfer de lectura por conexión (bytes)
SOCKET_REPLY_QUEUE1024Longitud de la cola de respuestas por conexión
SOCKET_REPLY_BATCH64Número máximo de respuestas agrupadas en una sola escritura
SWEEP_INTERVAL_SECS5Intervalo de limpieza de claves expiradas (segundos)
CLUSTER_SELF(ninguno)Dirección anunciada de este nodo host:port. Si está presente, activa el modo clúster
CLUSTER_PEERS(ninguno)Lista de direcciones de nodos (separadas por comas). El orden = prioridad de promoción, debe incluir self, mínimo 2
CONFIG./conf/ticketing.tomlRuta del archivo de configuración

Único vs clúster

  • Único (1 nodo): si no hay [cluster] (ni CLUSTER_*), es un nodo único. Es lo más rápido, pero al reiniciar hay una breve interrupción y el estado, al ser en memoria, se pierde al reiniciar (lease actúa como red de seguridad).
  • Clúster (sin interrupciones): mínimo 2 nodos. Cada nodo tiene el mismo CLUSTER_PEERS (en orden de prioridad) y su propio CLUSTER_SELF apuntando a sí mismo. De entre los nodos vivos, el de mayor prioridad se convierte en activo y el resto son standbys que reciben replicación en tiempo real. Para más detalles, consulta Cómo funciona y Protocolo — servidor ↔ servidor.

El despliegue en clúster de Kubernetes usa StatefulSet + servicio headless. Se hace que cada pod tenga un nombre DNS estable (ticketing-0.ticketing…, ticketing-1.ticketing…), esos nombres se colocan en CLUSTER_PEERS en orden de prioridad, y el CLUSTER_SELF de cada pod se inyecta automáticamente mediante la downward API (metadata.name).

Reinicio sin interrupciones (rolling)

  1. Reinicia primero los standbys, uno por uno (el activo sigue prestando servicio).
  2. Por último, detén el activo (Ctrl+C); mediante el handoff un standby se promueve y los clientes conmutan hacia él.
  3. Si vuelves a levantar el antiguo activo que habías bajado, se une como standby del activo actual (no hay failback automático).

Referencias

  • Imagen: sarolab/ticketing · Github: saro-lab/ticketing
  • En el cliente (broker), registra las direcciones de todos los nodos para que la conmutación ante fallos sea automática. Para el uso específico de cada lenguaje, consulta Bibliotecas.