Multi-Server

QuestsTracker unterstuetzt die Multi-Server-Synchronisierung ueber Redis. Diese Seite erklaert, wie Sie ein Multi-Server-Deployment konfigurieren und warten.

Einzelner Server?

Wenn Sie nur einen Server haben, lassen Sie redis.enabled: false in Ihrer config.yml. Das Plugin funktioniert einwandfrei ohne Redis.

Architektur

Server 1 (Survival)     Server 2 (Abenteuer)     Server 3 (Event)
       |                       |                       |
       └───────────┬───────────┘───────────────────────┘
                   |
              Redis Server
                   |
              MySQL / MariaDB

Alle Server teilen sich:

• Dieselbe Datenbank MySQL/MariaDB (ueber die BetonQuest-Konfiguration)
• Denselben Redis-Server fuer die Echtzeit-Synchronisierung

Voraussetzungen

Komponente	Version	Beschreibung
Redis	6.0+	Cache-Server und Pub/Sub-Messaging
MySQL/MariaDB	8.0+ / 10.5+	Gemeinsame Datenbank (in BetonQuest konfiguriert)
Netzwerk	—	Verbindung zwischen allen Servern, Redis und der Datenbank

Redis-Konfiguration

Redis installieren

# Ubuntu/Debian
sudo apt update && sudo apt install redis-server

# CentOS/RHEL
sudo yum install redis

# Docker
docker run -d --name redis -p 6379:6379 redis:latest

Redis absichern

Fuer ein Produktions-Deployment:

# /etc/redis/redis.conf
requirepass ihr_redis_passwort
bind 0.0.0.0  # Oder die spezifische Server-IP

Plugin-Konfiguration

Konfigurieren Sie auf jedem Server die config.yml:

redis:
  enabled: true
  host: "redis-adresse"
  port: 6379
  password: "ihr_redis_passwort"

Identische Konfiguration

Alle Server muessen auf denselben Redis-Server und dieselbe BetonQuest-Datenbank verweisen.

Funktionsweise der Synchronisierung

Redis Pub/Sub-Kanaele

Das Plugin verwendet zwei Kommunikationskanaele:

Kanal	Beschreibung
quest-updates	Statusaenderungen (Aktivierung, Abschluss, Fortschritt)
quest-purge	Bereinigung von Spielerdaten fuer ein Paket

Synchronisierungszyklus

1. Ein Spieler schliesst eine Quest auf Server 1 ab
2. Server 1 aktualisiert die Datenbank
3. Server 1 veroeffentlicht eine Nachricht auf dem Kanal quest-updates
4. Server 2 und Server 3 empfangen die Nachricht
5. Sie invalidieren ihren lokalen Cache fuer diesen Spieler
6. Der naechste Lesezugriff verwendet die aktuellen Daten aus der Datenbank

Heartbeat-System

Wenn ein Spieler den Server wechselt:

1. Der Spieler trennt die Verbindung zu Server 1
2. Die Redis-Daten bleiben 2 Minuten gueltig (Heartbeat)
3. Der Spieler verbindet sich mit Server 2
4. Server 2 ruft die Daten aus Redis ab (L2-Cache — schnell)
5. Kein Neuladen aus der Datenbank erforderlich

Wenn der Spieler sich nicht innerhalb von 2 Minuten erneut verbindet, verfallen die Redis-Daten und werden bei der naechsten Verbindung aus der Datenbank neu geladen.

Zweistufiger Cache

Das Plugin verwendet ein zweistufiges Cache-System fuer optimale Leistung:

Stufe	Typ	Latenz	TTL	Beschreibung
L1	Caffeine (lokal)	Sub-Millisekunde	1-2 Min	Speicher-Cache auf jedem Server
L2	Redis (verteilt)	~1 ms	2 Min	Gemeinsamer Cache zwischen Servern

Lesereihenfolge

L1 (lokal) → L2 (Redis) → Datenbank

1. L1 — Lokaler Speicher-Cache (am schnellsten)
2. L2 — Verteilter Redis-Cache (bei L1-Miss)
3. Datenbank — Wahrheitsquelle (bei L2-Miss)

Wenn Daten aus der Datenbank geladen werden, werden sie automatisch in L1 und L2 zwischengespeichert.

Schutzmechanismen

Circuit Breaker

Wenn Redis nicht verfuegbar wird:

• Nach 3 aufeinanderfolgenden Fehlschlaegen wird der Circuit Breaker aktiviert
• Redis-Operationen schlagen lautlos fehl (kein Fehler-Spam)
• Das Plugin arbeitet nur im Datenbank-Modus
• 30 Sekunden Abkuehlphase vor erneutem Versuch
• Wenn Redis wieder verfuegbar wird, setzt die Synchronisierung automatisch fort

Rate Limiting

Redis-Veroeffentlichungen werden auf 100ms Debounce pro Spieler begrenzt, um den Redis-Server nicht mit schnellen Updates zu ueberlasten.

Verbindungspool

• Maximum: 128 Verbindungen
• Minimum Idle: 16 Verbindungen
• Test bei Entleihe/Rueckgabe fuer Zuverlaessigkeit

Diagnose

Redis-Verbindung pruefen

/kgquests redis

Zeigt an:

• Verbindungsstatus (verbunden/getrennt)
• Anzahl der Schluessel im Cache (Fortschritt, Tracking, Status)
• Gesamtzahl der Schluessel

Spieler-Cache pruefen

/kgquests redis <Spieler>

Zeigt an:

• Existenz und TTL der Fortschrittsschluessel
• Existenz und TTL der Tracking-Schluessel
• Anzahl der Statusschluessel
• Warnung bei fehlenden Schluesseln

Leistungsstatistiken

/kgquests stats

Zeigt die Trefferquoten pro Cache (L1 und L2) an.

Gesamtzustand

/kgquests health

Prueft alle Komponenten: Datenbank, Redis, Cache, Scoreboard.

Haeufige Probleme

Redis nicht erreichbar

Symptom: /kgquests redis zeigt "Getrennt" an

Loesungen:

1. Ueberpruefen Sie, ob Redis laeuft: redis-cli ping (muss PONG antworten)
2. Ueberpruefen Sie die Firewall: Port 6379 muss zwischen den Servern offen sein
3. Ueberpruefen Sie das Passwort in config.yml
4. Ueberpruefen Sie die Serverlogs auf Verbindungsfehler

Daten zwischen Servern nicht synchronisiert

Symptom: Quests werden nicht aktualisiert, wenn ein Spieler den Server wechselt

Loesungen:

1. Ueberpruefen Sie, ob alle Server auf dasselbe Redis verweisen: /kgquests redis
2. Ueberpruefen Sie, ob alle Server dieselbe BetonQuest-Datenbank verwenden
3. Erzwingen Sie ein Refresh: /kgquests refresh <Spieler>
4. Ueberpruefen Sie den Circuit Breaker in den Logs

Hohe Latenz

Symptom: Das Menue oder das Scoreboard ist langsam

Loesungen:

1. Ueberpruefen Sie die Redis-Latenz: /kgquests benchmark
2. Ueberpruefen Sie die Datenbank-Latenz: /kgquests health
3. Platzieren Sie Redis im selben Netzwerk wie Ihre Minecraft-Server (idealerweise Latenz < 1ms)
4. Ueberpruefen Sie die Cache-Trefferquoten: /kgquests stats

Produktionsempfehlungen

Leistung

• Platzieren Sie Redis im selben Netzwerk wie Ihre Minecraft-Server (Latenz < 1ms)
• Verwenden Sie MariaDB statt MySQL fuer bessere Leistung
• Ueberwachen Sie die Trefferquoten mit /kgquests stats (Ziel: >95%)

Hochverfuegbarkeit

• Konfigurieren Sie Redis Sentinel oder Redis Cluster fuer Redundanz
• Verwenden Sie ein MySQL/MariaDB-Replikat fuer Sicherungen
• Ueberwachen Sie die Verbindungen mit /kgquests health

Sicherung

• Sichern Sie regelmaessig die MySQL/MariaDB-Datenbank
• Redis muss nicht gesichert werden (die Daten befinden sich in der Datenbank)
• Exportieren Sie Ihre config.yml und quests_config.yml

Siehe auch

• Installation — Initiale Redis-Konfiguration
• Konfiguration — Referenz der Redis-Schluessel
• Fehlerbehebung — Verbindungsprobleme