Protocole — Serveur ↔ Serveur (Cluster) ​

Le protocole RPC entre pairs, utilisé uniquement en mode cluster. Les nœuds partagent un état de verrou unique via le consensus Raft — chaque changement d'état de verrou (acquisition, libération, expiration) n'est appliqué qu'après la proposition du leader → la réplication majoritaire → le commit, si bien que l'exclusion mutuelle tient même pendant une partition ou un basculement. Voir Comment ça marche pour l'explication conceptuelle.

Flux — d'une acquisition à son commit ​

Le leader transforme la commande de verrou en commande répliquée, la transporte dans un RPC AppendEntries, et valide dès qu'une majorité, lui compris, l'a enregistrée (avec 3 nœuds, le leader plus un suiveur suffit — il n'attend pas le reste). La réponse au client ne part qu'après le commit, donc dès que vous avez reçu une réponse, ce verrou est inscrit dans la majorité.

Règles de port et d'adresse ​

• Le RPC entre pairs utilise un port Raft dédié = port client + 1000 (par ex. 5225 → 6225). Il est dérivé automatiquement sans clé de configuration séparée, et n'écoute qu'en mode cluster. Votre pare-feu doit ouvrir les deux ports.
• La configuration (cluster_self/cluster_peers) contient toujours l'adresse client. Seul l'appel (dial) vers un pair ajoute +1000 au port — l'adresse de redirection M (redirigé) donnée aux clients est toujours l'adresse client telle quelle.
• Les rôles sont distingués uniquement par le port — il n'existe aucune étape dans le protocole pour différencier client et pair. Voir Connexion et authentification pour l'ordre de connexion et les règles d'authentification/TLS.

Table des matières ​

• Communication serveur-serveur
  • Connexion et authentification
  • Structure de trame
  • Types de RPC
  • Commandes répliquées
  • Snapshot
• Paramètres Raft
• Configuration (variables d'environnement)
• Procédure de redémarrage progressif

Voir aussi ​

• Une explication simple de l'élection du leader, des commits majoritaires et des scénarios de panne — Comment ça marche
• Comment un client trouve le leader — M · Redirigé, Règles de correspondance des réponses
• Des configurations de déploiement réelles (Docker, Kubernetes, etc.) — Déploiement du serveur Ticketing