Multi-serveur

QuestsTracker supporte la synchronisation multi-serveur via Redis. Cette page explique comment configurer et maintenir un deploiement multi-serveur.

Serveur unique ?

Si vous n'avez qu'un seul serveur, laissez redis.enabled: false dans votre config.yml. Le plugin fonctionne parfaitement sans Redis.

Architecture

Serveur 1 (Survie)     Serveur 2 (Aventure)     Serveur 3 (Event)
       |                       |                       |
       └───────────┬───────────┘───────────────────────┘
                   |
              Redis Server
                   |
              MySQL / MariaDB

Tous les serveurs partagent :

• La meme base de donnees MySQL/MariaDB (via la configuration BetonQuest)
• Le meme serveur Redis pour la synchronisation en temps reel

Prerequis

Composant	Version	Description
Redis	6.0+	Serveur de cache et messagerie Pub/Sub
MySQL/MariaDB	8.0+ / 10.5+	Base de donnees partagee (configuree dans BetonQuest)
Reseau	—	Connexion entre tous les serveurs, Redis et la BDD

Configuration Redis

Installation de Redis

# 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

Securiser Redis

Pour un deploiement en production :

# /etc/redis/redis.conf
requirepass votre_mot_de_passe_redis
bind 0.0.0.0  # Ou l'IP specifique du serveur

Configuration du plugin

Sur chaque serveur, configurez config.yml :

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

Configuration identique

Tous les serveurs doivent pointer vers le meme serveur Redis et la meme base de donnees BetonQuest.

Fonctionnement de la synchronisation

Canaux Redis Pub/Sub

Le plugin utilise deux canaux de communication :

Canal	Description
quest-updates	Changements de statut (activation, completion, progression)
quest-purge	Purge de donnees joueur pour un package

Cycle de synchronisation

1. Un joueur termine une quete sur le Serveur 1
2. Le Serveur 1 met a jour la base de donnees
3. Le Serveur 1 publie un message sur le canal quest-updates
4. Le Serveur 2 et le Serveur 3 recoivent le message
5. Ils invalident leur cache local pour ce joueur
6. La prochaine lecture utilise les donnees a jour depuis la BDD

Systeme de heartbeat

Quand un joueur change de serveur :

1. Le joueur se deconnecte du Serveur 1
2. Les donnees Redis restent valides pendant 2 minutes (heartbeat)
3. Le joueur se connecte au Serveur 2
4. Le Serveur 2 recupere les donnees depuis Redis (cache L2 — rapide)
5. Pas besoin de recharger depuis la base de donnees

Si le joueur ne se reconnecte pas dans les 2 minutes, les donnees Redis expirent et sont rechargees depuis la BDD a la prochaine connexion.

Cache a deux niveaux

Le plugin utilise un systeme de cache a deux niveaux pour des performances optimales :

Niveau	Type	Latence	TTL	Description
L1	Caffeine (local)	Sub-milliseconde	1-2 min	Cache memoire sur chaque serveur
L2	Redis (distribue)	~1 ms	2 min	Cache partage entre serveurs

Ordre de lecture

L1 (local) → L2 (Redis) → Base de donnees

1. L1 — Cache local en memoire (le plus rapide)
2. L2 — Cache Redis distribue (si L1 miss)
3. BDD — Source de verite (si L2 miss)

Quand une donnee est chargee depuis la BDD, elle est automatiquement mise en cache dans L1 et L2.

Mecanismes de protection

Circuit breaker

Si Redis devient indisponible :

• Apres 3 echecs consecutifs, le circuit breaker s'active
• Les operations Redis echouent silencieusement (pas de spam d'erreurs)
• Le plugin fonctionne en mode BDD uniquement
• Cooldown de 30 secondes avant de retenter
• Quand Redis redevient disponible, la synchronisation reprend automatiquement

Rate limiting

Les publications Redis sont limitees a 100ms de debounce par joueur pour eviter de surcharger le serveur Redis avec des mises a jour rapides.

Pool de connexions

• Maximum : 128 connexions
• Minimum idle : 16 connexions
• Test on borrow/return pour la fiabilite

Diagnostics

Verifier la connexion Redis

/kgquests redis

Affiche :

• Statut de connexion (connecte/deconnecte)
• Nombre de cles en cache (progression, tracking, statuts)
• Total des cles

Verifier le cache d'un joueur

/kgquests redis <joueur>

Affiche :

• Existence et TTL des cles de progression
• Existence et TTL des cles de tracking
• Nombre de cles de statut
• Alerte si des cles sont manquantes

Statistiques de performance

/kgquests stats

Affiche les taux de hit par cache (L1 et L2).

Sante globale

/kgquests health

Verifie tous les composants : BDD, Redis, cache, scoreboard.

Problemes courants

Redis inaccessible

Symptome : /kgquests redis affiche "Deconnecte"

Solutions :

1. Verifiez que Redis est demarre : redis-cli ping (doit repondre PONG)
2. Verifiez le firewall : le port 6379 doit etre ouvert entre les serveurs
3. Verifiez le mot de passe dans config.yml
4. Verifiez les logs serveur pour les erreurs de connexion

Donnees desynchronisees entre serveurs

Symptome : Les quetes ne se mettent pas a jour quand un joueur change de serveur

Solutions :

1. Verifiez que tous les serveurs pointent vers le meme Redis : /kgquests redis
2. Verifiez que tous les serveurs utilisent la meme BDD BetonQuest
3. Forcez un refresh : /kgquests refresh <joueur>
4. Verifiez le circuit breaker dans les logs

Latence elevee

Symptome : Le menu ou le scoreboard est lent

Solutions :

1. Verifiez la latence Redis : /kgquests benchmark
2. Verifiez la latence BDD : /kgquests health
3. Placez Redis sur le meme reseau que vos serveurs Minecraft (latence < 1ms ideale)
4. Verifiez les taux de hit cache : /kgquests stats

Recommandations production

Performance

• Placez Redis sur le meme reseau que vos serveurs Minecraft (latence < 1ms)
• Utilisez MariaDB plutot que MySQL pour de meilleures performances
• Surveillez les taux de hit avec /kgquests stats (objectif : >95%)

Haute disponibilite

• Configurez Redis Sentinel ou Redis Cluster pour la redondance
• Utilisez un replica MySQL/MariaDB pour les sauvegardes
• Monitorez les connexions avec /kgquests health

Sauvegarde

• Sauvegardez regulierement la BDD MySQL/MariaDB
• Redis n'a pas besoin d'etre sauvegarde (les donnees sont dans la BDD)
• Exportez votre config.yml et quests_config.yml

Voir aussi

• Installation — Configuration initiale de Redis
• Configuration — Reference des cles Redis
• Depannage — Problemes de connexion