系統設計入門: Leader Election
當需要介接第三方服務時，我們會設置middle servers，避免外部服務可以直接對我們開發的db直接改寫資料，為確保執行過程資料一致性，而有middle servers的leader election。
推動畫看leader election過程：
http://thesecretlivesofdata.com/raft/
Leader Election
在演算法中，透過投票選出單一執行個體作為領導者(leader)，負責管理其他執行個體(follower)，並協調分散式系統中的所有執行的動作。
好處:
- 確保執行個體彼此不會衝突
- 避免造成共用資源爭用
- 干擾其他執行個體正在執行工作
但要如何選出 Leader?
Paxos & Raft
為兩種不同的consensus algorithm。以下範例以易懂的Raft介紹：
角色依據投票分為跟隨者(Follower)、候選人(Candidate)、領導者(Leader)，每隔一段時間都將由候選人發起投票。
透過每隔一段時間，由最先timeout的server發出投票，並由其他server回應，回應票數如果過半，發出者就是leader。
而當如果今天有任一server故障，仍不影響投票機制，但可能改變leader。
如下圖，當Node C故障，則依據timeout再繼續下一輪投票。
Leader負責與Client溝通，並將資訊同步到其他node server(followers)
回顧目的在於
處理故障容錯，在節點故障或是因為網路問題導致node間溝通中斷時，如何讓整個集群的狀態維持一致。
Raft 於在 2013 年與指導教授 John Ousterhout 共同發表《In Search of an Understandable Consensus Algorithm》，該篇文章更於 2014 年獲得 Best Paper Award (USENIX Annual Technical Conference) 。
