本文長期記錄一些raft相關的問題，主要是面試被問到的。不會介紹raft的基本原理，而是一些細節和異常情況的優化。
正常來說，乙個節點在掛了之後重新加入集群，是以follower的身份，需要等待一定時間才能開始選舉。但是為什麼不設計成掛了之後以candidate的身份，一加入就開始選舉投票呢？從正確性的角度上來說，這不會影響raft的正確性：如果新加入的節點立刻開始選舉，選舉成功即為leader，失敗即為follower。同時假設leader掛了，那麼這個時候相當於群龍無首，就算立刻把leader拉起來，也要等待一定的選舉時間才能選舉出新leader，開始處理業務。如果拉起來就能立刻選舉的話，能有效減少等待選舉的時間。既然這種設計不會帶來錯誤，同時又在某些corner case上表現不錯，為什麼工業上不這麼設計呢？
a: 主要是從工業實際執行的穩定性上考慮的。雖然分布式系統，crash是常態，但是正常執行的時間始終是佔大多數的。如果掛了的節點拉起來之後重置為candidate，那麼會比原來多出很多leader無緣無故切換的情況，擾亂系統穩定性。因此不推薦這種做法。（小聲：那對於原來是leader的節點，crash之後重置為candidate立刻開始投票可不可以呢？）
在raft中，雖然採取了隨機時間選舉，但是假設一下現在多個節點同時開始選舉，那麼選舉是不可能成功的，因為每個節點都會首先把票投給了自己。那麼我們突發奇想一下，假設所有節點發起投票時，不首先把票投給自己呢？這樣的話，還是有可能選舉失敗（三節點：a投給b，b投給c，c投給a，每個節點各一票）。同時在其他場景中，如果出現網路分割槽（分為多數派和少數派），假設多數派節點數為３，少數派為２。那麼理論上來說多數派節點可以選舉出leader對外提供服務，但如果選舉的時候不投給自己，可能就因為這一票永遠無法選舉出leader，因此這種做法不可選。
a, b, c三節點，只有a和b之間的網路不通，而c是可以和a, b 連通的，有什麼辦法優化？由於leader a和b無法連通，b會選舉成為新leader (c 會投給它)。同時leader a的心跳包會被拒絕，降級為follower(因為term的原因)。過一段時間後，a也會經歷一樣的過程，選舉成為leader，b降級為follower，如此反覆。
應該辦法是在系統中去detect這種網路分割槽，如果發現了的話，要及時修復連線。以及c其實可以觀測到頻繁的leader切換，從而報警，或者自己選舉成為新leader。好奇其他演算法是怎麼做的。
raft相關問題
commit時機 在領導 將建立的 志條 複製到 多數的伺服器上的時候，志條 就會被提交。同時，領導 的 志中之前的所有 志條 也都會被提交，包括由其他領導 建立的條 旦跟隨者知道 條 志條 已經被提交，那麼他也會將這個 志條 應 到本地的狀態機中 按照 志的順序 1，領導 在 個任期 在指定的 個...
隨機選擇演算法相關問題
給定乙個整數組成的集合，集合中的整數各不相同，現在要將它分為兩個子集合，使得這兩個子集合的並為原集合 交為空集，同時在兩個子集合的元素個數n1與n2之差的絕對值 n1 n2 盡可能小的前提下，要求他們各自的元素之和s1和s2之差的絕對值 s1 s2 盡可能大。求 s1 s2 使用隨機選擇演算法的原理...
排序演算法相關
1.1氣泡排序 氣泡排序的基本原理是 依次比較相鄰的兩個數，將大數放在前面，小數放在後面，也即首先比較第乙個和第二個數，將大數放在前面，小數放在後面。然後比較第2個數和第3個數，將大數放前，小數方後，依次直至比較最後兩個數。如此在第一輪最後的數必定是所有數中最小的，然後重複以上過程將所有小數放在最後...