Upgrade to Pro — share decks privately, control downloads, hide ads and more …

RAFT: A story on how clusters of computers keep your data in sync

RAFT: A story on how clusters of computers keep your data in sync

Joshua Thijssen

January 25, 2020
Tweet

More Decks by Joshua Thijssen

Other Decks in Programming

Transcript

  1. How do we make sure that... !5 ➡ Data stays

    consistent ➡ Servers can fail at any time ➡ Don’t rely on unreliable means (time, id’s, network etc)
  2. Replicated State Machine !6 #1 set Y=5 #2 inc Y

    #3 set X = 3 Journal / Log State machine Y=5 Y=6 Y=6, X=3
  3. Where? ➡ etcd / CoreOS ➡ Zookeeper ➡ MongoDB ➡

    ElasticSearch ➡ ...basically everything clustered !7
  4. !12 ➡ Proven to be correct ➡ Designed for simplicity

    ➡ Relatively easy to implement ➡ "Good enough" for most cases
  5. ➡ Cluster of servers, usually 3 or 5. ➡ One

    single leader. ➡ Clients communicate with leader only. ➡ Leader sends logs to other members. !13
  6. !24

  7. 25

  8. 26 Servers Quorum Size Failure Tolerance 1 1 0 2

    2 0 3 2 1 4 3 1 5 3 2 6 4 2 7 4 3
  9. !29 1 2 3 4 5 6 7 8 9

    10 11 12 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 3 x←5 3 x←4 index command term committed uncommitted
  10. !30 Leader 1 2 3 4 5 6 7 8

    9 10 11 12 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 3 x←5 3 x←4 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 Followers 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 Leader receives commands and applies to log 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7
  11. !31 Leader 1 2 3 4 5 6 7 8

    9 10 11 12 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 3 x←5 3 x←4 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 Followers 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 3 x←5 3 x←4 3 x←5 3 x←4 Leader pushes entries to the cluster 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7
  12. !32 Leader 1 2 3 4 5 6 7 8

    9 10 11 12 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 3 x←5 3 x←4 Followers Leader commits after majority and OKs to client 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 3 x←5 3 x←4 3 x←5 3 x←4 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7
  13. !33 Leader 1 2 3 4 5 6 7 8

    9 10 11 12 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 3 x←5 3 x←4 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 Followers 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 3 x←5 3 x←4 3 x←5 3 x←4 Followers receives logs and commitIndex from leader 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 1 x←3 1 x←1 1 y←9 2 x←2 3 x←0 3 y←7 3 x←5 3 x←4 3 x←5 3 x←4
  14. !34 1 2 3 4 5 6 7 8 9

    10 11 12 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 6 6 6 6 6 6 6 6 6 6 6 6 7 7 3 3 3 3 3 a b c d e f
  15. 1007 1008 1009 1010 1011 1012 24 x←5 24 x←4

    24 x←2 24 y←4 1 2 3 4 1006 1 x←3 1 x←1 1 y←9 2 x←2 23 y←7 ... Snapshots last included index: 1006 last included term: 23 Y=7, X=4,Z="aap"
  16. !38 ➡ #1 For any given term, there can be

    at most one leader. ➡ #2 A server will vote for at most one candidate per term. ➡ #3 If two logs contain an entry with the same index and term, both logs are identical up to the given index.
  17. !39 ➡ #4 The leader in a term contains all

    the entries committed in previous terms. ➡ #5 Leaders always append new entries to logs. Entries are in leaders are never overwritten or deleted. ➡ #6 If server S1 applies committed log entry 'e' at index 'i' to its state machine, then no other server can apply a different committed log entry at index 'i' to theirs.