# Algorep

### Présentation - 15 min

* Introduction
* Structure
* Élection
* REPL
* Commandes et réplication de logs
* Améliorations

### Démo Live - 5 min

### Questions - 5 min

---
> Parler des **choix d'implémentation** et des **mesures de performance**

## Introduction

### Raft vs Paxos

**Paxos**:
* 1989
* utilisé par MySQL / Cassandra
* Consensus assez dur à comprendre.

**Raft**:
* 2014
* utilisé par Kubernetes / Zookeeper, donc intéressant de comprendre le fonctionnement des clusters Kafka.
* beaucoup plus de documentation, [Raft Paper](https://raft.github.io/raft.pdf) qui contient les principes d'implementation et [Raft Website](https://raft.github.io/) qui propose des outils de visualisation
* reste malgré tout complexe et demande de comprendre l'ensemble du consensus

### Pourquoi Go ?

* une occasion d'apprendre un nouveau langage
* simple d'écriture
* Idéal pour l'asynchrone avec les goroutines, les systèmes distribués de manière générale et un système de transmission de messages intégrés via les channels

## Structure

* N serveurs qui vont être instanciés dans une classe qui nous sert de couche d'abstraction et de REPL
* ils vont tous avoir un état parmi cette liste:
- Follower
- Candidate
- Leader
- Dead
* ils possèdent également chacun d'autres variables internes:
- ID (id du serveur)
- channels de communication
- currentTerm (le terme)
- votedFor (le vote attribué, -1 par défaut)
- log (liste des logs)
* première version synchrone (channels bloquants)
* beaucoup de questionnements sur comment faire communiquer les serveurs entre eux de manière asynchrone
* la bonne solution -> utiliser la lib rpc de golang, mais compliqué à mettre en place pour nous
* notre solution intuitive -> pour chaque type de rpc (appendentries/requestvote) et type de requête (request/reply) on va avoir un channel dédié
* on aurait pu fusionner les channels d'AppendEntries et RequestVote mais on voulait garder un typage au niveau des channels pour simuler au maximum le comportement des rpc
* on va donc envoyer notre requête dans le channel "request" associé à un serveur et recevoir notre réponse dans le channel "response" qui lui est attribué
* chaque serveur a exactement le même fonctionnement, il va lancer une fonction **Run()** qui va démarrer une goroutine possédant un switch case écoutant directement sur les différents channels
* en fonction des messages reçus et de l'état actuel du serveur, certaines fonctions vont être exécutées faisant ainsi avancer le processus

## Élection

* Raft repose sur un système de leadership très prononcé comparé aux autres consensus
* toutes les requêtes des clients vont en effet passer par un seul serveur le **Leader**, et c'est lui-même qui va envoyer une réponse au client
* c'est le processus d'élection qui va vraiment démarrer le consensus puisque les serveurs sont fondamentalement identiques
* ce qui va faire qu'un serveur envoie une requête de vote avant les autres c'est un compteur interne paramétré de manière aléatoire entre **150** et **350** ms
* quand ce compteur tombe à 0, il va changer son état en **Candidate** et envoyer une requête de vote à tous les autres serveurs avec son ID
* Lorsqu'un serveur reçoit une requête de vote, 2 possibilités : soit il a déjà timeout, est déjà candidat et a donc voté pour lui-même, soit il n'avait pas encore timeout et va voter pour celui qui lui a envoyé la première requête de vote et devenir Follower. 1 vote par serveur par élection bien sûr
* s'il obtient la majorité, il passera au status de **Leader** et commencera à envoyer des AppendEntries (Heartbeats) de manière régulière et sera chargé de communiquer avec notre REPL pour soumettre les requêtes au cluster

## REPL

* Couche omnisciente qui peut changer le comportement de nos serveurs comme les ralentir ou les assassiner de sang-froid
* Dans notre code, ce ralentissement se manifeste par un sleep
* Il existe 3 types de vitesse, rapide (0 latence), normal (0,5 s) et lent (1 s)
* Toutes ces directives sont passées par message sur le channel **orderChan** du ou des serveurs concernés
* Par défaut, nos serveurs sont en rapide. Dans notre programme, si l'on ralentit la vitesse de notre leader, les Followers vont prendre trop de temps à recevoir le message du Leader et vont lancer une nouvelle élection
* Le leader se doit d'être rapide
* Si l'on commet un homicide sur un serveur, il ne peut plus interagir du tout, que ce soit avec des HeartBeats ou durant les élections

## Distributed File System

* Système de réplication de fichiers distribué dans chacun de nos serveurs
* Il existe différentes commandes possibles pour les clients:
- Submit (permet de donner un fichier d'instruction au REPL)
- Load (charge un fichier et le stock sur chaque serveur et renvoie un uuid)
- List (affiche tous les fichiers)
- Delete (supprime un fichier)
- Append (écrit dans un fichier)
* Toutes les commandes sont parsées par le REPL et envoyées au Leader du cluster
* Le Leader va ensuite diffuser la commande à tous les serveurs
* Si la commande est acceptée par la majorité, la commande est commit et une notification est envoyée dans un channel qui sera lu par le REPL et affichée dans le terminal pour le client

## Améliorations

* implémenter le recover, il marche actuellement mais de manière fallacieuse car les attributs volatiles lastApplied et commitIndex ne sont pas reset lors du crash
* on peut stocker ces variables dans un storage et les load lors du recovery
* l'ajout de snapshot consiste simplement à sauvegarder les logs dans un autre storage
* utiliser la lib rpc