menuTicketing

Ticketing-Server-Bereitstellung

Umgebung
Modus
bash
Beispiel für Client-Verbindung
rust
Schnelltest mit nc
bash

Umgebungsvariablen

Jeder Eintrag der (optionalen) ticketing.toml lässt sich auch als Umgebungsvariable setzen. Die Priorität ist Umgebungsvariable > ticketing.toml > Standardwert, und bei Schlüsseln/Boolean-Werten wird Groß-/Kleinschreibung nicht unterschieden. Das Docker-Image basiert auf scratch, daher ist die Konfiguration per Umgebungsvariable der Standardweg (um stattdessen eine Konfigurationsdatei zu verwenden, diese mounten und den Pfad über CONFIG angeben).

UmgebungsvariableStandardwertBeschreibung
PORT (SERVER_PORT)5225TCP-Listen-Port. Im Cluster-Modus ignoriert, stattdessen wird der Port von CLUSTER_SELF verwendet
DEBUG (SERVER_DEBUG)je nach BuildBei 1/true Debug-Log
SOCKET_BIND0.0.0.0Listen-Adresse
SOCKET_NODELAYtrueTCP_NODELAY
SOCKET_READ_BUF_LEN4096Lesepuffer pro Verbindung (Bytes)
SOCKET_REPLY_QUEUE1024Länge der Antwortwarteschlange pro Verbindung
SOCKET_REPLY_BATCH64Maximale Anzahl an Antworten, die in einem write gebündelt gesendet werden
SWEEP_INTERVAL_SECS5Bereinigungsintervall für abgelaufene Schlüssel (Sekunden)
CLUSTER_SELF(keiner)Angekündigte Adresse dieses Nodes host:port. Falls gesetzt, Cluster-Modus
CLUSTER_PEERS(keiner)Liste der Node-Adressen (kommagetrennt). Reihenfolge = Promote-Priorität, self inbegriffen, mindestens 2
CONFIG./conf/ticketing.tomlPfad der Konfigurationsdatei

Single vs. Cluster

  • Single (1 Node): Ohne [cluster] (bzw. CLUSTER_*) läuft der Server als Single-Node. Am schnellsten, aber beim Neustart entsteht eine kurze Unterbrechung, und der Zustand liegt im Speicher, geht also beim Neustart verloren (lease dient als Sicherheitsnetz).
  • Cluster (unterbrechungsfrei): mindestens 2 Nodes. Jeder Node hat dieselben CLUSTER_PEERS (in Prioritätsreihenfolge) und ein auf sich selbst zeigendes CLUSTER_SELF. Von den lebenden Nodes wird der mit der höchsten Priorität zum Active, die übrigen bleiben als Standby und erhalten die Replikation in Echtzeit. Für die Funktionsweise im Detail siehe Funktionsweise und Protokoll — Server ↔ Server.

Für die Kubernetes-Cluster-Bereitstellung werden StatefulSet + Headless Service verwendet. Jeder Pod erhält dadurch einen stabilen DNS-Namen (ticketing-0.ticketing…, ticketing-1.ticketing…); diese Namen werden in Prioritätsreihenfolge in CLUSTER_PEERS eingetragen, und CLUSTER_SELF jedes Pods wird über die Downward API (metadata.name) automatisch injiziert.

Rolling Restart (unterbrechungsfrei)

  1. Zuerst die Standbys einzeln neu starten (der Active bleibt weiterhin im Dienst).
  2. Wird zum Schluss der Active beendet (Ctrl+C), promotet der Handoff den Standby, und die Clients wechseln über.
  3. Wird der heruntergefahrene alte Active wieder gestartet, tritt er als Standby des aktuellen Active bei (kein automatisches Failback).

Siehe auch