raft演算法的目的及工作過程：
raft演算法是為了保證在超過半數的伺服器正常工作的情況下仍然可以達成一致，像乙個整體一樣工作，並且一少部分慢的機器不會影響系統的整體效能的一致性演算法。
raft演算法開始時在集群中選舉出領導人負責日誌複製的管理，領導人接受來自客戶端的請求並把該日誌複製給集群中的其它伺服器，然後通知其它伺服器提交該日誌。領導人必須保證其它伺服器與它的日誌同步，當領導人宕掉後會自發選舉出新的領導人。
領導人選取：
1） 如何成為領導人：
候選人在選舉過程中獲得大多數選票，以獲得大多數選票做判斷標準就可以防止選舉過程中出現兩個領導人的情況，因為每個伺服器只能投一票，所以不可能有兩台伺服器同時獲得超過半數的選票。候選人獲得某台伺服器選票的條件是候選人的任期不能小於伺服器最後知道的任期號，而且該伺服器之前沒有投票給其它的候選人，並且候選人的日誌要比該伺服器新或者一樣新（此舉是為了日誌複製與提交的安全性，會在後面詳細闡述）。
2） 選票被瓜分怎麼辦：
在選舉過程中若是有多台追隨者同時成為候選人，難免會出現候選人獲得一樣票數的情況，根據上述的大多數原則要重新開始下一輪的選舉，並且此時的任期號需要加1。而為了防止這種瓜分情況，每台伺服器等待超時的時間都是隨機設定的，這樣就可以減少同時超時的概率了。
日誌複製：
1） 如何保證日誌的一致性：
日誌複製採取的是覆蓋原則，領導人強制追隨者們複製它的日誌來處理日誌的不一致，即通過nextindex的遞減來找到追隨者們最後一條與它匹配的日誌，並用領導人之後的日誌來覆蓋追隨者們之後不匹配的日誌。這個方法看似很危險，但是通過之後的安全性中的闡述可以看到，採取覆蓋的方法並不會出現危險性。
安全性：
1） 如何防止已經提交的日誌被覆蓋：
之所以會出現這種情況，是因為乙個日誌較舊的伺服器成為了領導人，解決措施是候選人發出requestvote rpc時，要附上自己最新的一條日誌。收到這個rpc的伺服器比較這條日誌和自己最新的日誌。如果自己的日誌較新，一定投出反對票。
2） 日誌的提交要求：
如果要提交的日期是當前任期，則可以根據大多數原則，即當大多數伺服器有此日誌時，它可以被提交。如果要提交的是之前任期的日誌，則它不可以單獨提交，而是應該與當前任期的日誌一起提交。因為如果只提交之前任期的日誌，則在提交之後，有可能被新出現的領導人覆蓋。
就如上圖中（c）（d）所示，索引2處的日誌已經被提交了，但是由於s5成為了領導人，它強行覆蓋了日誌2，但是如果（e）中索引2和3處的日誌能夠同時提交，s5根本不會成為領導人，就不會出現這種情況。
對booth演算法的一點理解
最近學到了booth演算法，不太理解，看了網上很多解釋，感覺wiki和知乎的乙個回答裡解釋的比較好 在這裡寫一點我自己的理解 乙個用的比較多的解釋booth演算法的例子是 0011 1100 它可以寫成0100 0000 0000 0010 為了方便理解我們可以在表示中引進 1，這樣就可以寫成010...
對 threadfence的一點理解
一直沒搞清楚,cuda 2.2版增加的 threadfence到底有何作用,直到今天看到sdk 3.0手冊 中的下面例子才恍然大悟.中文為我的理解,嘿嘿 乙個求和的例子 device unsigned int count 0 統計有幾個block結束的變數 shared bool islastblo...
對GBDT的一點理解
gbdt由一系列的回歸樹組成，如下圖所示 樹的深度未必都要一樣，下圖僅為示意圖 gbdt原理 針對每乙個類別訓練一系列的回歸樹，再累加每個類別回歸樹的 值得到針對每個類別的最終的 值。單獨拿乙個類別來說，訓練的過程中假設需要 的值為f xi 實際的值為yi 有loss function l yi,f...