2015-08-27 1 views
2

Lorsque le leader reçoit une entrée de journal, il la réplique sur les autres serveurs du cluster. Ensuite, il valide l'entrée et indique aux autres serveurs de valider également. Il semble y avoir deux cas ici:
1) Le chef valide l'entrée et indique ensuite aux autres serveurs de valider.
2) Le leader dit à tout le monde de s'engager et ensuite il le fait aussi. En # 1, si le leader se bloque avant de dire aux autres de commettre, alors celui qui devient le nouveau chef utilise-t-il l'entrée même si elle n'est pas validée? Sinon, nous avons des journaux qui ne sont pas synchronisés pour la dernière entrée. (L'ancien chef l'aurait appliqué et l'autre n'aurait pas eu.) Si oui, alors comment sait-il que c'est acceptable de le commettre? Dans le n ° 2, si le leader se bloque avant de pouvoir commettre, tous les autres nœuds tombent en panne après leur validation, puis dans l'élection, l'ancien leader redevient le nouveau leader, puis les autres serveurs ont des entrées validées. le nouveau chef n'a pas. Que se passe-t-il dans ce cas?Existe-t-il une condition de concurrence dans RAFT?

Répondre

3

Il est important de noter la différence entre une entrée stockée sur un serveur, l'entrée en cours de validation et l'entrée appliquée. L'engagement est pratiquement un concept théorique. Dans la plupart des cas, les serveurs ne font rien pour valider une entrée. Il est commis par le fait qu'il est stocké sur une majorité de serveurs et donc garanti pour ne pas être perdu. Les entrées peuvent être appliquées lorsqu'elles sont validées ou à un moment ultérieur, à condition que les serveurs les appliquent dans l'ordre.

En raison de la nature des systèmes distribués, il est impossible pour tous les serveurs de valider une entrée en même temps. Au lieu de cela, Raft garantit seulement qu'une entrée est a persisté sur la majorité des serveurs au moment où le leader l'applique à sa machine d'état. La plupart des implémentations de Raft prennent l'approche n ° 1 afin de permettre au leader d'appliquer la commande à sa machine d'état et de répondre au client avant que d'autres serveurs ne l'appliquent à leurs machines d'état.

Que se passerait-il si un chef applique une commande et échoue alors est la suivante:

* We know that the command has been stored on a majority of servers therefore... 
* Raft's election algorithm guarantees that the next server that's elected has that entry 
* When the next leader is elected, it will append a no-op entry to its log and commit it 
* Once the no-op entry is committed, the leader will increase its commitIndex to that of the no-op entry and thereby commit all entries remaining from the previous term (including the original leader's last commit) 
* On the next heartbeat, the leader will send the index of the no-op as the `commitIndex` 
* Remaining followers will be replicated entries up to the leader's no-op and commit entries from the previous leader's term 

Est-ce que sens? Donc, ce qui est important à noter est que même si un leader n'a pas la possibilité d'informer les adeptes qu'une entrée a été validée, Raft garantit que le prochain leader aura les entrées validées du premier leader, et ce leader éventuellement répliquer ces entrées à des suiveurs qui n'en ont pas déjà et l'index de validation continuera au-delà du dernier index du leader précédent.

Références: Voir la section 5.4.2 du papier Raft (https://ramcloud.atlassian.net/wiki/download/attachments/6586375/raft.pdf) pour plus d'informations sur l'engagement des entrées de termes antérieures

+0

BTW le forum 'raft-dev' est un bon endroit pour poser ce genre de questions. Je ne suis pas sûr si Diego suit cette balise: https://groups.google.com/forum/m/#!forum/raft-dev – kuujo

0

Réponse à # 1. Oui, le nouveau leader aura toujours la valeur validée en raison de la "Restriction d'élection" qui a été appliquée pour assurer la complétude du leader qui définit cela. "Si une entrée est validée dans un terme, alors tous les journaux de dirigeants à terme plus élevé seront sûrement avoir cette entrée ".