Merge branch 'master' of https://github.com/Laurent2916/ASR-slides

slides.md

@@ -27,6 +27,8 @@ Stanford University
 (2014)
 </footer>
 
+<!-- mascotte: annie -->
+
 <!-- Laurent -->
 
 ---
@@ -41,11 +43,18 @@ Stanford University
 
 > Consensus algorithms allow a collection of machines to work as a coherent group that can survive the failures of some of its members. – RAFT authors
 
+<!-- Pour citer les auteurs de raft (dans leur abstract) -->
+
 <!-- Les algorithmes de consensus permettent à un ensemble de machines de fonctionner comme un groupe cohérent qui peut survivre aux défaillances de certains de ses membres. -->
 
 <br>
 
-- Accord sur l'état partagé (image système unique)
+<!-- Donc globalement ça veut dire qu'un algorithme de consensus doit permettre / permet -->
+
+<!-- accord implique réparation  -->
+<!-- en découle que c'est un point clé pour build sys cohérent -->
+
+- Accord sur l'état du système (image système unique et partagée)
 - Réparation (réplication) autonome en cas de défaillance d'un serveur
   - Une minorité de serveurs HS: pas de problème
   - La majorité des serveurs HS: perte de disponibilité, maintien de la cohérence
@@ -67,7 +76,7 @@ Stanford University
 
 <!--
 
-- Replicated log -> replicated state machine
+- Replicated state machine <- Replicated log (inférence)
   - All servers execute same commands in same order
 - Consensus module ensures proper log replication
 - System makes progress as long as any majority of servers up
@@ -121,8 +130,6 @@ Paxos domine le marché depuis ~25 ans (Leslie Lamport, 1989)
 
 <!-- Les auteurs de RAFT en avait donc ras le bol de voir cette situation, ils ont donc décidés de créer un nouvel algorithme, en se fondant sur la compréhensibilité -->
 
-<!-- Clément -->
-
 ## Prendre des décisions de conception fondées sur la compréhensibilité
 
 <!-- Pour se faire ils ont choisis de décomposer le consensus le plus possible en des petits problèmes trivials à résoudre. -->
@@ -131,6 +138,10 @@ Paxos domine le marché depuis ~25 ans (Leslie Lamport, 1989)
 
 <!-- Il ont aussi essayé de diminuer l'espace des états possibles lors du fonctionnement de l'algorithme pour le rendre le plus simple possible. -->
 
+<!-- Une pière deux coup, c'est moins de code, moins de trucs à comprendre -->
+<!-- rejoint l'idée traiter plusieurs mécanismes en même temps -->
+<!-- rendre les états "prédictibles" (assez ironique sachant qu'ils utilisent de l'aléatoire) -->
+
 - Minimiser l'espace des états
   - Traiter plusieurs problèmes avec un seul mécanisme
   - Éliminer les cas particuliers
@@ -147,6 +158,12 @@ Paxos domine le marché depuis ~25 ans (Leslie Lamport, 1989)
 
 </header>
 
+<!-- Élection: Ils ont décidé de partir sur un modèle "strong leader" où le leader est source de vérité. Même si ça implique l'overhead de l'élection... ils ont trouvé que c'était plus facile à comprendre. -->
+
+<!-- Réplication des logs: modèle hiérarchique, le serveur dicte à chaque candidats les modifications à apppliquer à ses journeaux. (append uniquement, sauf cas spéciaux qu'on verra après) -->
+
+<!-- Sécurité: par de réparation active du leader des journeaux (par exemple juste après un crash), raft essaie de maintenir le plus possible la cohérence des journeaux et ainsi contourne le problème. -->
+
 1. Élection d'un leader (mandat)
    - Sélectionner un serveur qui sera le leader
    - Détecter les pannes, choisir un nouveau leader
@@ -294,6 +311,8 @@ Normal Operation:
 
 -->
 
+<!-- Laurent & Clément -->
+
 ---
 
 <header>