Cómo funciona ​

Esta página recorre el flujo real de mensajes entre un cliente y el servidor (clúster) para explicar cómo funciona Ticketing. La especificación exacta a nivel de bytes de lo que cruza la red está en Protocolo (API) y Protocolo (clúster).

Estructura general ​

Los servicios que reciben las solicitudes de los usuarios (por ejemplo, los servidores de eventos que gestionan la apertura de una venta de entradas) hacen cola con la misma clave frente al clúster de Ticketing, y solo el servidor al que le llega el turno continúa con el trabajo, como descontar inventario o asignar un asiento.

Adquisición y liberación de un bloqueo ​

El flujo básico. Una clave libre se concede de inmediato; una clave ocupada espera su turno en la cola FIFO. Cuando el poseedor la libera, el bloqueo se entrega directamente al primero de la cola sin volver a competir por él — el siguiente en espera continúa de inmediato con un nuevo token, así que nunca hay un momento en que el bloqueo quede vacío, y nadie puede colarse.

• lease es una red de seguridad. Si un cliente muere u olvida liberar el bloqueo, en cuanto transcurre la duración de lease el servidor recupera la clave y la entrega al siguiente en espera. Configúralo con margen — más largo que el peor caso posible de tu sección crítica. v1 solo admite de 1 a 250 segundos; los trabajos más largos no están soportados y se rechazan.
• wait es el límite superior de espera de un cliente. Si su turno no llega dentro de ese tiempo, el servidor responde con T (timeout) en lugar de conceder el bloqueo, así que nunca se filtra ningún bloqueo. 0 significa un único intento inmediato sin entrar en la cola. No existe una espera infinita.
• Si el mismo cliente intenta volver a adquirir una clave que ya posee, hace cola igual que cualquier otro — no es un bloqueo reentrante.

Consulta Matriz de solicitud × estado de clave para las reglas completas del comportamiento del servidor según el estado de la clave, y Restricciones de campos para los rangos de valores de los campos.

Tokens de fencing ​

Incluso un servidor de bloqueo perfecto no puede controlar el reloj de un cliente. Ticketing por sí solo no puede evitar el caso del poseedor obsoleto: un cliente que se congeló un rato por pausas de GC o sobrecarga mientras poseía el bloqueo, y luego despierta — sin saber que su lease ya expiró — y continúa su trabajo. Por eso el token de cada respuesta de adquisición es un entero u64 garantizado para aumentar en cada concesión. En bases financieras o persistentes, la comparación y actualización del high-water de fencing por clave debe ser atómica con la escritura de negocio real, en la misma transacción de DB o una única escritura condicional. Actualizar primero solo la fila de fencing y hacer la escritura real después no es seguro.

La monotonía se mantiene también en el clúster — el propio contador de tokens se replica mediante consenso, así que incluso tras un cambio de líder, el nuevo líder siempre continúa desde un número mayor que el anterior. Consulta Token de fencing (especificación) para el formato exacto del campo.

Clúster — sin interrupciones vía consenso Raft ​

En modo clúster, los nodos comparten un único estado de bloqueo mediante consenso Raft. Solo el líder atiende las solicitudes de los clientes, y cada cambio de estado del bloqueo (adquisición, liberación, expiración) solo se confirma tras que una mayoría de nodos lo haya registrado. Conectarse a un nodo que no es el líder produce una respuesta M (movido) que apunta al líder.

• Si el líder muere, la configuración actual elige uno nuevo en unos 2,3-2,5 segundos. El mismo acquire lógico solo puede continuar dentro del presupuesto wait restante si no se envió ningún byte de la solicitud. Un acquire enviado sin respuesta confirmada es Indeterminate y nunca se reenvía automáticamente.
• Incluso la expiración de lease pasa por el consenso. Un bloqueo solo desaparece cuando el líder confirma el comando de expiración, así que pequeñas diferencias de reloj entre nodos nunca hacen que el estado del bloqueo diverja.
• Si el clúster pierde la mayoría (p. ej. 2 de 3 nodos caídos), deja de aceptar escrituras en lugar de arriesgarse a emitir un bloqueo incorrecto (seguridad ante todo). Si se pierde el estado volátil del proceso de 2 de 3 (o 3 de 5) nodos, ese dominio cluster/fencing no debe recuperarse ni iniciarse automáticamente con la misma identidad.

Como lo que importa es la mayoría, solo se permiten 3 o 5 nodos. Un número par de nodos solo añade coste sin mejorar la tolerancia a fallos, así que el servidor se niega a arrancar con uno.

Consulta Protocolo (clúster) para el formato de tramas y las reglas de puertos entre pares, y sustitución sin interrupciones por learner con NodeId nuevo para sustituir los nodos uno a uno.

Comportamiento del cliente ​

Los clientes oficiales comparten el siguiente comportamiento (consulta Bibliotecas para las API específicas de cada lenguaje).

• Mantiene una conexión persistente por dirección en segundo plano. Dada una única dirección, mantiene dos conexiones a ese mismo nodo, de modo que un corte breve en un socket no interrumpe el servicio.
• Elige la conexión priorizando al líder y luego por turno rotativo (round-robin). Recuerda el líder al que fue redirigido por última vez mediante M y envía las siguientes solicitudes directamente a él.
• Las solicitudes se canalizan (pipelining). La siguiente solicitud puede enviarse sin esperar una respuesta — consulta Reglas de emparejamiento de respuestas para saber cómo se emparejan las respuestas con las solicitudes.
• Una conexión caída sigue reintentando con retroceso exponencial (0,1 s hasta un tope de 3,2 s). Una conexión muerta no rompe el objeto broker — se recupera por sí sola.
• El mismo acquire lógico solo se reintenta internamente si no se envió ningún byte de la solicitud. Un B correlacionado es Busy/no adquirido definitivo y vuelve inmediatamente al caller sin reintento interno. M solo es un leader hint para la conexión siguiente; al no tener owner/key, no justifica reenviar una solicitud pending ya enviada. Un acquire enviado sin respuesta confirmada se informa como Indeterminate y no permite entrar en la sección crítica.
• La liberación explícita y la compensación de token conocido usan coincidencia exacta de owner/token/key y una cola dedicada acotada. Los reintentos terminan en un plazo absoluto de 5 segundos desde request/enqueue, no al final del lease restante. Sin respuesta de éxito, la liberación explícita no se declara ni supone exitosa; el lease del servidor es la última red.

Conexiones y seguridad ​

Toda conexión (de cliente o entre pares) se establece en el orden TCP → (TLS) → autenticación por desafío-respuesta. El cliente combina el nonce enviado por el servidor con su token mediante un hash para responder, de modo que el token nunca viaja en texto plano por la red, y un nonce nuevo en cada conexión descarta cualquier reintento de repetición (replay). Consulta Protocolo de autenticación para la especificación exacta.

Nota sobre la consistencia ​

• La exclusión mutua está garantizada por el consenso. Como toda concesión pasa por un commit de mayoría, la misma clave nunca se emite a dos poseedores a la vez, ni siquiera durante una partición de red o un cambio de líder.
• Las bases persistentes deben imponer fencing. Solo una condición high-water por clave, ejecutada atómicamente con la escritura protegida en la misma transacción/escritura condicional, puede detener a un cliente que despierta tras expirar su lease. El bloqueo ordena el trabajo; el fencing de DB bloquea la última escritura obsoleta.