Multi-Server

QuestsTracker unterstützt die Multi-Server-Synchronisierung über Redis. Diese Seite erklärt, 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 (über die BetonQuest-Konfiguration)
• Denselben Redis-Server für 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

Für 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 müssen auf denselben Redis-Server und dieselbe BetonQuest-Datenbank verweisen.

Funktionsweise der Synchronisierung

Redis Pub/Sub-Kanäle

Das Plugin verwendet zwei Kommunikationskanäle:

Kanal	Beschreibung
quest-updates	Statusänderungen (Aktivierung, Abschluss, Fortschritt)
quest-purge	Bereinigung von Spielerdaten für ein Paket

Synchronisierungszyklus

1. Ein Spieler schließt eine Quest auf Server 1 ab
2. Server 1 aktualisiert die Datenbank
3. Server 1 veröffentlicht eine Nachricht auf dem Kanal quest-updates
4. Server 2 und Server 3 empfangen die Nachricht
5. Sie invalidieren ihren lokalen Cache für diesen Spieler
6. Der nächste 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 gültig (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 nächsten Verbindung aus der Datenbank neu geladen.

Zweistufiger Cache

Das Plugin verwendet ein zweistufiges Cache-System für 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 verfügbar wird:

• Nach 3 aufeinanderfolgenden Fehlschlägen wird der Circuit Breaker aktiviert
• Redis-Operationen schlagen lautlos fehl (kein Fehler-Spam)
• Das Plugin arbeitet nur im Datenbank-Modus
• 30 Sekunden Abkühlphase vor erneutem Versuch
• Wenn Redis wieder verfügbar wird, setzt die Synchronisierung automatisch fort

Rate Limiting

Redis-Veröffentlichungen werden auf 100ms Debounce pro Spieler begrenzt, um den Redis-Server nicht mit schnellen Updates zu überlasten.

Verbindungspool

• Maximum: 128 Verbindungen
• Minimum Idle: 16 Verbindungen
• Test bei Entleihe/Rückgabe für Zuverlässigkeit

Diagnose

Redis-Verbindung prüfen

/kgquests redis

Zeigt an:

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

Spieler-Cache prüfen

/kgquests redis <Spieler>

Zeigt an:

• Existenz und TTL der Fortschrittsschlüssel
• Existenz und TTL der Tracking-Schlüssel
• Anzahl der Statusschlüssel
• Warnung bei fehlenden Schlüsseln

Leistungsstatistiken

/kgquests stats

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

Gesamtzustand

/kgquests health

Prüft alle Komponenten: Datenbank, Redis, Cache, Scoreboard.

Häufige Probleme

Redis nicht erreichbar

Symptom: /kgquests redis zeigt "Getrennt" an

Lösungen:

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

Daten zwischen Servern nicht synchronisiert

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

Lösungen:

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

Hohe Latenz

Symptom: Das Menü oder das Scoreboard ist langsam

Lösungen:

1. Überprüfen Sie die Datenbank-Latenz: /kgquests health
2. Platzieren Sie Redis im selben Netzwerk wie Ihre Minecraft-Server (idealerweise Latenz < 1ms)
3. Überprüfen 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 für bessere Leistung
• Überwachen Sie die Trefferquoten mit /kgquests stats (Ziel: >95%)

Hochverfügbarkeit

• Konfigurieren Sie Redis Sentinel oder Redis Cluster für Redundanz
• Verwenden Sie ein MySQL/MariaDB-Replikat für Sicherungen
• Überwachen Sie die Verbindungen mit /kgquests health

Sicherung

• Sichern Sie regelmäßig 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-Schlüssel
• Fehlerbehebung — Verbindungsprobleme