Architecture initiale et interfaces fondamentales

L'élaboration d'un moteur de consensus distribué basé sur Raft exige une gestion rigoureuse des états, des réseaux et de la concurrence. Le point d'entrée de votre implémentation se situe généralement dans le fichier principal de votre module, par exemple raft/node.go, tandis que la suite de tests se trouve dans raft/node_test.go. Il est fortement recommandé d'exécuter les tests avec le détecteur de conditions de course activé (-race).

Le cœur du système repose sur une structure principale qui doit exposer les méthodes suivantes pour interagir avec la couche de service :

// Initialisation d'un nœud Raft au sein du cluster
func NewRaftNode(cluster []*rpc.ClientEnd, nodeID int, storage *StateStorage, commitChan chan CommitMsg) *RaftNode

// Soumission d'une nouvelle commande au journal
func (rn *RaftNode) SubmitCommand(cmd interface{}) (logIdx int, currentTerm int, isLeader bool)

// Récupération de l'état actuel du nœud
func (rn *RaftNode) GetCurrentState() (term int, leader bool)

// Structure de message envoyée à la couche service lors d'un commit
type CommitMsg struct {
    CommandValid bool
    Command      interface{}
    Index        int
    Term         int
    Snapshot     []byte
}

Le paramètre cluster représente les points de terminaison réseau de tous les nœuds, y compris le nœud actuel. La méthode SubmitCommand doit être non bloquante et retourner immédiatement. Dès qu'une entrée est validée par la majorité, le nœud doit injecter un CommitMsg dans le canal commitChan. Toutes les communications inter-nœuds doivent exclusivement utiliser le framework RPC fourni, sans aucun recours à des variables partagées ou au système de fichiers local.

Élection du leader et battements de cœur

La première phase consiste à implémenter le mécanisme d'élection. L'objectif est de garantir qu'un leader soit élu et maintienne son statut via des battements de cœur (AppendEntries vides). Si le leader tombe en panne, un nouveau doit être élu rapidement.

Points clés de l'implémentation :

• Ajoutez les champs d'état définis dans le papier original (terme courant, vote accordé, état du nœud) à votre structure principale.
• Implémentez les gestionnaires RPC pour RequestVote. Un nœud déclenche une élection s'il ne reçoit aucune communication avant l'expiration de son délai d'attente.
• Le délai d'expiration doit être aléatoire (par exemple, entre 300 et 500 ms) pour éviter les élections simultanées et les scissions de votes.
• Les battements de cœur doivent être envoyés périodiquement (par exemple, toutes les 100 ms). Évitez d'utiliser time.Ticker ou time.Timer de Go, car leur gestion dans des environnements de test simulés peut être erratique. Préférez des goroutines dédiées avec des appels time.Sleep() conditionnels.
• N'oubliez pas de vérifier régulièrement si le nœud a été terminé (via une méthode isKilled()) pour éviter les fuites de goroutines.

Réplication du journal et cohérence

Une fois l'élection stabilisée, le leader doit répliquer les commandes. Lorsqu'un client appelle SubmitCommand, le leader ajoute l'entrée à son journal local et la diffuse via des RPC AppendEntries.

Défis techniques :

• Respectez la restriction d'élection (section 5.4.1 du papier) : un candidat ne peut gagner que si son journal est au moins aussi à jour que celui des votants.
• Évitez les boucles actives (busy-waiting) lors de l'attente de la réplication. Utilisez des variables de condition (sync.Cond) ou des canaux pour réveiller les goroutines d'envoi uniquement lorsque de nouvelles entrées sont disponibles.
• Assurez-vous que l'index de commit (commitIndex) n'est avancé que lorsque la majorité des nœuds a répliqué l'entrée, et que cette entrée appartient au terme actuel du leader.

Persistance de l'état et optimisation du retour en arrière

Pour survivre aux redémarrages, les nœuds doivent persister certaines variables (terme courant, vote, et l'intégralité du journal). Utilisez le mécanisme de sérialisation fourni pour encoder ces données en octets lors de chaque modification, et les décoder lors de l'initialisation.

Une optimisation cruciale pour les performances consiste à accélérer la synchronisation des journaux divergents. Au lieu de décrémenter nextIndex d'un seul pas à la fois, le suiveur peut renvoyer des informations sur le conflit :

// Structure de réponse optimisée pour AppendEntries
type AppendEntriesReply struct {
    Success        bool
    Term           int
    ConflictTerm   int // Terme de l'entrée en conflit
    ConflictIndex  int // Premier index du terme en conflit
    FollowerLogLen int // Longueur totale du journal du suiveur
}

// Logique de mise à jour de nextIndex côté Leader
func (rn *RaftNode) handleConflict(peer int, reply *AppendEntriesReply) {
    if reply.ConflictTerm != -1 {
        lastIdx := rn.findLastIndexForTerm(reply.ConflictTerm)
        if lastIdx != -1 {
            // Le leader possède ce terme : on saute directement à la fin de ce terme
            rn.nextIndex[peer] = lastIdx + 1
        } else {
            // Le leader n'a pas ce terme : on recule jusqu'au premier index du suiveur
            rn.nextIndex[peer] = reply.ConflictIndex
        }
    } else {
        // Le journal du suiveur est simplement trop court
        rn.nextIndex[peer] = reply.FollowerLogLen
    }
}

Compactage du journal via instentanés

Pour éviter une croissance infinie de la mémoire, le journal doit être compacté. La couche service appelle périodiquement CreateSnapshot(index, data) pour indiquer que les entrées jusqu'à index peuvent être supprimées.

Mécanismes à implémenter :

• Tronquez le journal en mémoire. Assurez-vous de supprimer les références aux anciennes entrées pour permettre au ramasse-miettes de Go de libérer la mémoire.
• Implémentez le RPC InstallSnapshot. Si un leader tente d'envoyer une entrée qui a déjà été compactée, il doit envoyer l'instantané complet au suiveur retardataire.
• Lors de la réception d'un instantané, le suiveur doit le transmettre à la couche service via le canal de commit. L'instantané ne doit faire avancer l'état que s'il est plus récent que l'état actuel.
• L'état Raft et les données de l'instantané doivent être persistés atomiquement.

Piège courant : Conflit d'application des instantanés

Un problème fréquent survient lorsqu'un suiveur reçoit un instantané alors qu'il est en train de traiter des entrées de journal plus anciennes. Par exemple, si le suiveur a les entrées 1 à 8 en attente de commit, et reçoit soudainement un instantané couvrant les index 1 à 9, l'application asynchrone de l'entrée 8 après l'instantané corrompra l'état de la machine.

Pour résoudre cela, centralisez la logique d'application. Lorsqu'un instantané est reçu et validé, mettez à jour immédiatement l'index de commit et le dernier index appliqué. La boucle d'application principale doit vérifier si l'index de l'entrée à appliquer est strictement supérieur au dernier index couvert par l'instantané avant de l'envoyer à la couche service. Ne permettez jamais à une goroutine de traitement de journal d'écraser un état plus récent établi par un instantané.