Ticketing Go-Bibliothek ​

Repository ​

Beispiel ​

Einfaches Beispiel ​

Einen Broker beim App-Start erstellen und teilen. wait=0 ist ein sofortiger Versuch ohne Queue, maximal 255 s; lease liegt bei 1–250 s. Das letzte Minimum-Work-Budget ist Pflicht und darf null sein. Teilsekunden werden aufgerundet; Werte außerhalb des Bereichs oder Budget über der normalisierten Lease werden vor dem Senden abgelehnt und nie geclampt.

import ticketing "github.com/saro-lab/ticketing/ticketing-go"

broker := ticketing.Connect("127.0.0.1:5225")
broker.WaitReady(ctx, 5*time.Second)

ticket, err := broker.Acquire(ctx, "key", 5*time.Second, 30*time.Second, 2*time.Second)
if err != nil {
    return err
}
defer ticket.Close()
token := ticket.Token
// In the same DB transaction: verify/update token high-water and perform the business write.

Automatisches Close/Drop ist ein begrenzter Best-effort-Release. Wenn das Ergebnis zählt, die explizite Release-API nutzen. Der Token muss den geschützten DB-Write in derselben Transaktion fencen.

Wissenswertes zum Verhalten ​

• Sobald ein Request-Byte gesendet worden sein könnte, führt eine verlorene definitive Antwort zu Indeterminate. Kein automatisches A mit demselben Owner; der Caller betritt die Critical Section nicht.
• Cancel vor Send ist unsent; nach possible-send wird die Session geschlossen. Wurde gleichzeitig ein Grant-Token geparst, folgt ein begrenzter kompensierender exact-token Release.
• M, jedes E und malformed/oversized/unknown Responses sind session-fatal. Ungeklärte possible-send Acquires werden Indeterminate.
• B ist definitive Capacity-Ablehnung und kommt sofort. Kein interner Retry; der Caller kann mit App-Backoff und neuem Owner einen neuen Acquire starten.
• Explizite/kompensierende Releases versuchen exact token nur bis absolut 5 Sekunden ab call/enqueue. R ist Erfolg, N bereits weg/nicht aktuell; keine finale Antwort ist Fehler, nie angenommener Erfolg.
• Ticket gibt es nur bei positiver konservativer Restzeit und ausreichendem Work-Budget. Arbeit über 250 s ist vor Send unsupported.
• Token-DB-Fencing ist Pflicht: in derselben Transaktion token <= stored_high_water ablehnen, High-water und Business Write aktualisieren, dann commit/rollback und release.

Sicherheitsoptionen (Token · TLS) ​

Alle Optionen sind optional. Token sollte mit den client_tokens des Servers übereinstimmen, und TLS hat vier Modi: aus / System-Vertrauensspeicher / eine angegebene CA / Verifikation überspringen (nur für Tests).

broker, err := ticketing.New(ticketing.Options{
    Addrs: []string{"10.0.0.1:5225", "10.0.0.2:5225", "10.0.0.3:5225"},
    Token: "123",
    TLS:   ticketing.TLSSystemRoots(), // TLSOff() | TLSCa("ca.crt") | TLSInsecureSkipVerify()
})

Die serverseitige Token-, TLS- und Cluster-Konfiguration kannst du auf der Seite Ticketing-Serverbereitstellung erzeugen.