Raft 只讀操作優(yōu)化

為什么需要優(yōu)化只讀操作

raft是一個(gè)為分布式集群達(dá)成一致性的協(xié)議。對(duì)于集群需要保證一致性的數(shù)據(jù)，每次一操作其實(shí)都要確認(rèn)此操作是否在集群中達(dá)成了一致。從是否會(huì)改變數(shù)據(jù)的角度，操作就分兩個(gè)只讀操作與寫(xiě)操作。只讀操作顧名思義就是不會(huì)對(duì)數(shù)據(jù)做任何的改動(dòng)。寫(xiě)操作包含了增刪改等需要修改數(shù)據(jù)的操作，通俗說(shuō)就是這次操作處理完后，數(shù)據(jù)有可能跟操作前不一樣。

正是因?yàn)橹蛔x操作不對(duì)數(shù)據(jù)進(jìn)行修改，所以raft可以?xún)?yōu)化只讀操作。

因?yàn)橹灰蛻?hù)端請(qǐng)求的是現(xiàn)集群真正的leader，那么獲取到的數(shù)據(jù)就不會(huì)有錯(cuò)誤。一個(gè)只讀操作沒(méi)有必要征求整個(gè)raft集群的共識(shí)。畢竟使用raft達(dá)成一個(gè)操作的共識(shí)還需要多節(jié)點(diǎn)網(wǎng)絡(luò)請(qǐng)求與log持久化落磁盤(pán)等開(kāi)銷(xiāo)。

在恢復(fù)和安裝快照，或者是raft集群加入新節(jié)點(diǎn)同步log與數(shù)據(jù)的時(shí)，因?yàn)橹蛔x操作并沒(méi)有改變數(shù)據(jù)，所以不需要還原這些操作也能保持?jǐn)?shù)據(jù)的完整與一致，提高數(shù)據(jù)恢復(fù)的效率。

如何優(yōu)化

優(yōu)化只讀操作的核心就是保證此時(shí)請(qǐng)求到該集群leader確實(shí)是能夠向集群中法定人數(shù)的節(jié)點(diǎn)commit log成功。否則用戶(hù)可能會(huì)讀到陳舊的數(shù)據(jù)信息，無(wú)法保證線(xiàn)性一致。

用論文[1]中的話(huà)說(shuō)就是

leader必須擁有最新被提交的日志的信息

在處理只讀請(qǐng)求前，leader必須確認(rèn)自己是否已經(jīng)被替換掉了

圍繞這一核心目標(biāo)，raft的作者在他PhD論文[2]中提到了兩種優(yōu)化的方法。

一. 使用readIndex

使用commitIndex做為readIndex。這里需要注意??：當(dāng)一個(gè)leader剛被當(dāng)選時(shí)，雖然他肯定擁有最完整的信息，但leader無(wú)法確認(rèn)自己的commitIndex是最新的。所以這個(gè)leader必須發(fā)一個(gè)no-op的空白log。直到這個(gè)空白log被commit了，保證了commitIndex為最新的。再將最新的commitIndex做為readIndex。

發(fā)起一次心跳，當(dāng)收集到這次心跳返回ack中的commitIndex >= readIndex 且 commitIndex達(dá)到法定人數(shù)時(shí)。確認(rèn)leader擁有最新被提交的日志且自己就是集群中的合法leader。

leader的狀態(tài)機(jī)至少執(zhí)行到readIndex，保證線(xiàn)性一致性。

返回給狀態(tài)機(jī)，執(zhí)行這個(gè)只讀的操作給客戶(hù)。

readIndex這種方法，雖然避免不了網(wǎng)絡(luò)請(qǐng)求的開(kāi)銷(xiāo)，但是減少了raft的log，也避免了讀操作落磁盤(pán)的開(kāi)銷(xiāo)。

此方法實(shí)現(xiàn)以后，用戶(hù)可以向follower請(qǐng)求只讀操作，以保證負(fù)載均衡，增強(qiáng)系統(tǒng)讀的吞吐率。這里需要注意，follower的數(shù)據(jù)可能落后當(dāng)前l(fā)eader很多，或者網(wǎng)絡(luò)分區(qū)后跟隨了錯(cuò)誤的leader。所以，leader必須提供一個(gè)接口以返回當(dāng)前的readIndex。follower請(qǐng)求這個(gè)接口，拿到當(dāng)前的readIndex，然后leader執(zhí)行1-2，被請(qǐng)求的follower在自己的狀態(tài)機(jī)中執(zhí)行3-4步。

但是我覺(jué)得這種負(fù)載均衡的方法并不是很巧妙。第一，增加了系統(tǒng)復(fù)雜度，第二，有了讀放大，多了請(qǐng)求leader的網(wǎng)絡(luò)操作。第三，這種方法并不能保證用戶(hù)的寫(xiě)操作負(fù)載均衡。

現(xiàn)在系統(tǒng)一般使用對(duì)集群分組，對(duì)數(shù)據(jù)分片的方法來(lái)做負(fù)載均衡。這樣既不會(huì)增加raft協(xié)議的復(fù)雜度，同時(shí)對(duì)讀寫(xiě)操作都做了負(fù)載均衡。

二. 使用時(shí)鐘(lease read)

方法二就是使用租期（lease）時(shí)間。在租期未過(guò)期時(shí)，在不進(jìn)行任何網(wǎng)絡(luò)請(qǐng)求下，保證用戶(hù)只讀請(qǐng)求。

首先還是要記錄leader的commitIndex作為readIndex。但是不會(huì)專(zhuān)門(mén)發(fā)起一次心跳(一.中的2)。在租期不過(guò)期的情況下，保證leader的狀態(tài)機(jī)至少執(zhí)行到readIndex，給用戶(hù)返回只讀操作。

租期其實(shí)就是選舉的時(shí)間差。當(dāng)leader收到法定人數(shù)的心跳后，那么在raft系統(tǒng)設(shè)置超時(shí)選舉（election timeout）這段時(shí)間內(nèi)，自己的數(shù)據(jù)肯定是正確的。因?yàn)樵谶@段時(shí)間里，肯定不會(huì)有新的leader產(chǎn)生。

這里使用論文[2]中的一副圖來(lái)說(shuō)明情況

因?yàn)橐紤]到進(jìn)程調(diào)度，垃圾回收，虛擬機(jī)遷移，時(shí)鐘頻率不同等種種原因，需要設(shè)置一個(gè)bound（bound是大于1的）。其中start為leader向集群follower發(fā)送心跳的時(shí)間點(diǎn)。那么租期為：

當(dāng)收到法定人數(shù)的心跳點(diǎn)后，延長(zhǎng)一個(gè)租期(lease_time)。雖然使用lease這種方法減少了時(shí)鐘開(kāi)銷(xiāo)，但是如果這里的bound設(shè)置與現(xiàn)實(shí)不符，或者出現(xiàn)時(shí)鐘嚴(yán)重漂移等問(wèn)題。仍會(huì)導(dǎo)致舊leader可能給客戶(hù)返回陳舊數(shù)據(jù)。

作者在文章[2]中最后又提出了一種方法來(lái)避免這種情況。

服務(wù)器在返回apply日志時(shí)，把這個(gè)日志對(duì)應(yīng)的index也一并返回給用戶(hù)，用戶(hù)把這個(gè)日志的index保存起來(lái)，客戶(hù)將跟蹤與他們所看到的結(jié)果相對(duì)應(yīng)的最新索引，并在每次請(qǐng)求時(shí)將這些信息提供給服務(wù)端。如果服務(wù)端收到的客戶(hù)端請(qǐng)求的index大于服務(wù)器最新的applied的日志的index，則服務(wù)器不會(huì)為該請(qǐng)求提供服務(wù)。

不過(guò)這個(gè)描述我沒(méi)太看懂。。因?yàn)橐ＷC所有客戶(hù)端都能知道最新的applied 的index，感覺(jué)這種情況才能避免。

TiKV中提供了一種解決方案[3],有點(diǎn)像一和二的結(jié)合體。不同的是在每次寫(xiě)操作時(shí)，進(jìn)行租期的續(xù)約。如果長(zhǎng)時(shí)間沒(méi)有寫(xiě)操作，租期過(guò)期時(shí)，使用方法一（readIndex）進(jìn)行。

[1] Ongaro D, Ousterhout J. In search of an understandable consensus algorithm (extended version)[J]. 2013.

[2] Ongaro D. Consensus: Bridging theory and practice[D]. Stanford University, 2014.

[3] https://pingcap.com/blog-cn/lease-read/

總結(jié)

以上是生活随笔為你收集整理的当前只读状态:是_Raft 只读(read-only)优化的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。