Ticketing ¿Qué es Ticketing?
Ticketing es un servidor de bloqueo dedicado, diseñado para un único trabajo — el bloqueo distribuido. Es un único binario de servidor en Rust junto con clientes oficiales por lenguaje que implementan todos el mismo protocolo binario, byte a byte. Solo dos operaciones — adquirir y liberar —, una cola FIFO por clave, tokens de fencing y un clúster Raft opcional que activas cuando lo necesitas. Todo lo que un bloqueo distribuido necesita, y nada más.
¿En qué se diferencia de los bloqueos construidos sobre un almacén de datos?
La mayoría de los bloqueos distribuidos en producción se apoyan en un almacén clave-valor — un script de Lua o Redlock sobre Redis, o un bloqueo construido sobre las sesiones y arrendamientos (leases) de ZooKeeper o etcd. Redis es un excelente almacén, pero es un almacén clave-valor reutilizado para el bloqueo distribuido, no un sistema de bloqueo diseñado específicamente para ello, y eso se traduce en una sobrecarga estructural: el coste de análisis de un protocolo de propósito general y la sobrecarga de estructuras de datos de propósito general vienen incluidos.
Ticketing se diseñó exclusivamente para el bloqueo distribuido desde el primer día, así que cada capa está construida en torno a los bloqueos.
- Protocolo — campos binarios de ancho fijo, ni texto ni un formato de serialización de propósito general. Los valores se leen directamente por desplazamiento de bytes sin ningún análisis, y el pipelining permite enviar la siguiente solicitud sin esperar la respuesta anterior.
- Interior del servidor — todo el estado es una cola FIFO por clave más un temporizador de arrendamiento (lease). La ruta de la solicitud ni siquiera reserva memoria en el heap.
- Operación — arranca un único binario de servidor (o contenedor), configúralo con un puñado de variables de entorno, y listo. No hace falta diseño de esquemas, ni un almacén aparte, ni conocimiento operativo ajeno al bloqueo.
Rendimiento
- Gestiona más de 1 millón de operaciones por segundo usando menos de 10 MB de memoria
Por qué Ticketing
🚦 Integridad del orden — cola FIFO con entrega directa
El primero en llegar es el primero en ser atendido. Cuando el poseedor libera el bloqueo, este se entrega directamente al primero de la cola sin volver a competir por él. Sin inanición (starvation) causada por la contención de bloqueos basada en sondeo y reintento, y sin tormentas de reintentos.
🛟 Un cliente muerto no deja el bloqueo atascado — lease
Si el proceso que posee el bloqueo muere o su conexión se cae, el servidor lo recupera automáticamente en cuanto transcurre la duración de lease fijada al adquirirlo, y lo entrega al siguiente en espera. Olvidarse de liberarlo no detiene todo el sistema.
🔑 Prevención de trabajo fuera de orden — tokens de fencing
Hay un fallo que un bloqueo por sí solo no puede evitar: un poseedor que despierta tarde — sin saber que su lease ya expiró — y pide terminar su trabajo de todos modos. Ticketing emite un token de fencing que aumenta de forma monótona con cada adquisición. Basta con que el recurso protegido aplique una única regla — "rechazar cualquier token menor que el último visto" — para cerrar incluso este último resquicio. Consulta Cómo funciona para la explicación completa.
🗳️ Un clúster sin interrupciones basado en Raft
Un solo servidor ya es suficiente por sí mismo, pero cuando necesitas cero tiempo de inactividad, forma un clúster de 3 (o 5) nodos. Cada cambio de estado del bloqueo solo se confirma tras el acuerdo de una mayoría de nodos mediante el consenso Raft, así que el mismo bloqueo nunca se emite dos veces a la vez, ni siquiera si el líder muere o la red se particiona. Si el líder falla, se elige uno nuevo en aproximadamente un segundo y los clientes cambian automáticamente. El servicio sigue funcionando incluso cuando los nodos se apagan uno a uno — por ejemplo, durante reinicios de instancias en la nube o un mantenimiento progresivo.
🔒 Autenticación y TLS integrados
Toda conexión pasa por una autenticación por token de tipo desafío-respuesta inmediatamente después de conectarse, y el token nunca viaja en texto plano por la red. Cifra toda la conexión con TLS siempre que lo necesites.
🌐 El mismo protocolo, byte a byte, en todos los lenguajes principales
Rust, Java/Kotlin, JavaScript/TypeScript, Python, C#, Go, Ruby, C/C++ — todos los clientes oficiales implementan el mismo protocolo binario, con una API que resulta natural en el ecosistema de cada lenguaje (asíncrona o bloqueante). Un bloqueo adquirido desde cualquier lenguaje hace cola de forma justa junto a clientes escritos en cualquier otro. Consulta Bibliotecas para instrucciones de instalación y ejemplos.
Solo dos operaciones
Fiel a un servidor exclusivo de bloqueos, la superficie también es mínima.
- Asocia una clave al recurso que quieres proteger — p. ej.
order-1234,account-77,daily-batch. - Adquiere esa clave antes de hacer el trabajo — si alguien más la tiene, esperas tu turno en la cola FIFO.
- Libérala cuando el trabajo termine — el siguiente en espera la toma de inmediato, sin volver a competir por ella.
Las únicas opciones sobre estas dos operaciones son lease (recuperación automática) y waitTimeout (dejar de esperar) — esa es toda la API.
Qué leer a continuación
- Cómo se asignan realmente los bloqueos y cómo se mantiene el clúster en pie — Cómo funciona
- La especificación exacta a nivel de bytes de lo que cruza la red — Protocolo (API)
- Genera el comando de ejecución del servidor — Despliegue del servidor Ticketing