Leader Election
-
Imagine a situation where we might want our database to connect to a third party service (stripe, plaid, youtube, Google Analytics, etc.)
-
That would look like this:
<!-- -->
Third Party Service Database
[ ]<-------->[ Master ]
- This isn’t ideal: so we’ll put our own service which gates out certain functionality.
<!-- -->
Third Party Service Your Service Database
[ ]<-------->[ Leader ]<------->[ ]
- But here, we only have server that is a single point of failure.
- Let’s make it more redundant by adding more servers.
<!-- -->
Third Party Service Your Service Database
[ ]<-------->[ Leader ]<------->[ ]
[ ]<-------->[ Leader ]<------->[ ]
[ ]<-------->[ Leader ]<------->[ ]
[ ]<-------->[ Leader ]<------->[ ]
[ ]<-------->[ Leader ]<------->[ ]
-
But now, we want every operation to only occur once.
-
We can’t charge a person twice for the same invoice.
-
Leader Election has a server elect one of the servers as a
leader
, which is the only server that connects to the database.
<!-- -->
Third Party Service Your Service Database
[ ]<-------->[ Leader ]<------->[ ]
[ ]--------->[ Follower ]<------->[ ]
[ ]--------->[ Follower ]<------->[ ]
[ ]--------->[ Follower ]<------->[ ]
-
Now, all writes to the leader have to propagate to the followers in case of failure, and when the leader dies, then the followers have to relect a new leader.
-
Consensus building (Leader Election) is actually quite hard.
-
It’s hard to share some state.
-
We need a Consensus Algorithm to achieve this leader election.
Consensus Algorithms
-
Paxos
-
Raft
-
Two tools that implement Leader Election:
- Zookeeper
- Etcd
-
Etcd is a key-value store that is highly available and strongly consistent.
- Etcd uses Raft for leader election
-
Have Etcd use a key value that has a
leader
key set to a value of the leader server. -
Then, all the servers are strongly consistent and synced to a leader.
Prev: [replication-and-sharding](replication-and-sharding.md) Next: [peer-to-peer-networks](peer-to-peer-networks.md)