Biblioteca Ticketing para Rust
GitHub crates.ioRepositorio
Ejemplo
Ejemplo básico
Cree un broker al iniciar la aplicación y compártalo. wait=0 es un intento inmediato sin cola, máximo 255 s; lease es 1–250 s. El minimum-work budget final es obligatorio y puede ser cero. Las fracciones de segundo se redondean hacia arriba y los valores fuera de rango o un budget mayor que el lease normalizado se rechazan antes de enviar, nunca se clampan.
use std::time::Duration;
use ticketing::TicketBroker;
let broker = TicketBroker::connect(["127.0.0.1:5225"]);
broker.wait_ready(Duration::from_secs(5)).await;
let ticket = broker.acquire(
"key",
Duration::from_secs(5),
Duration::from_secs(30),
Duration::from_secs(2),
).await?;
let token = ticket.token();
// In the same DB transaction: verify/update token high-water and perform the business write.
ticket.release().await?;El close/drop automático es un release bounded best-effort. Use la API de release explícito si importa el resultado. El token debe aplicar fencing al write DB protegido dentro de la misma transaction.
Conviene saber (comportamiento)
- Si pudo enviarse un byte, perder la respuesta definitiva produce Indeterminate. No se reenvía
Aautomáticamente con el mismo owner; el caller no entra en la sección crítica. - Cancel antes de send es unsent; tras possible-send cierra la sesión. Si se parseó a la vez un grant token, intenta un release compensatorio exact-token limitado.
M, todos losEy respuestas malformed/oversized/unknown son session-fatal. Acquires possible-send no resueltos quedan Indeterminate.Bes rechazo definitivo de capacity y vuelve inmediatamente. Sin retry interno; el caller puede iniciar acquire nuevo con owner nuevo y backoff de aplicación.- Releases explícitos/compensatorios reintentan exact token solo durante 5 segundos absolutos desde call/enqueue.
Réxito,Nausente/no actual; sin respuesta final es error, nunca éxito supuesto. - Solo se entrega Ticket con tiempo conservador positivo suficiente para work budget. Trabajo superior a 250 s es unsupported antes de enviar.
- El fencing DB con token es obligatorio: en la misma transaction rechace
token <= stored_high_water, actualice high-water y haga business write antes de commit/rollback y release.
Opciones de seguridad (Token · TLS)
Todas las opciones son opcionales. token debe coincidir con client_tokens del servidor, y TLS tiene cuatro modos: desactivado / almacén de confianza del sistema / una CA indicada / omitir verificación (solo para pruebas).
use ticketing::{TicketBroker, TlsMode};
let broker = TicketBroker::builder()
.addrs(["10.0.0.1:5225", "10.0.0.2:5225", "10.0.0.3:5225"])
.token("123")
.tls(TlsMode::SystemRoots)
// .tls(TlsMode::Ca("ca.crt".into()))
// .tls(TlsMode::InsecureSkipVerify)
.connect()?;Puedes generar la configuración del token, TLS y el clúster en el lado del servidor en la página Despliegue del servidor Ticketing.