DLedger的Jepsen測(cè)試方法是什么-創(chuàng)新互聯(lián)

這篇文章主要講解了“DLedger的Jepsen測(cè)試方法是什么”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“DLedger的Jepsen測(cè)試方法是什么”吧！

成都創(chuàng)新互聯(lián)從2013年創(chuàng)立，先為洱源等服務(wù)建站，洱源等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為洱源企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。

分布式系統(tǒng)面臨的挑戰(zhàn)

Is it better to be alive and wrong or right and dead?隨著計(jì)算機(jī)技術(shù)的發(fā)展，系統(tǒng)架構(gòu)從集中式演進(jìn)到分布式。分布式系統(tǒng)相對(duì)于單臺(tái)機(jī)器來(lái)說(shuō)提供了更好的可擴(kuò)展性，容錯(cuò)性以及更低的延遲，但在單臺(tái)計(jì)算機(jī)上運(yùn)行軟件和分布式系統(tǒng)上運(yùn)行軟件卻有著根本的區(qū)別，其中一點(diǎn)便是單臺(tái)計(jì)算機(jī)上運(yùn)行軟件，錯(cuò)誤是可預(yù)測(cè)的。當(dāng)硬件沒(méi)有故障時(shí)，運(yùn)行在單臺(tái)計(jì)算機(jī)的軟件總是產(chǎn)生同樣的結(jié)果；而硬件如果出現(xiàn)問(wèn)題，那么后果往往是整個(gè)系統(tǒng)的故障。因此，對(duì)于單體系統(tǒng)來(lái)說(shuō)，要么功能完好且正確，要么完全失效，而不是介于兩者之間。

而分布式系統(tǒng)則復(fù)雜的多。分布式系統(tǒng)涉及到多個(gè)節(jié)點(diǎn)和網(wǎng)絡(luò)，因而存在部分失效的問(wèn)題。分布式系統(tǒng)中不可靠的網(wǎng)絡(luò)會(huì)導(dǎo)致數(shù)據(jù)包可能會(huì)丟失或任意延遲，不可靠的時(shí)鐘導(dǎo)致某節(jié)點(diǎn)可能會(huì)與其他節(jié)點(diǎn)不同步 ，甚至一個(gè)節(jié)點(diǎn)上的進(jìn)程可能會(huì)在任意時(shí)候暫停一段相當(dāng)長(zhǎng)的時(shí)間（比如由于垃圾收集器導(dǎo)致）而被宣告死亡，這些都給分布式系統(tǒng)帶來(lái)了不確定性和不可預(yù)測(cè)性。事實(shí)上，這些問(wèn)題在分布式系統(tǒng)中是無(wú)法避免的，就像著名的CAP理論中提出的，P（網(wǎng)絡(luò)分區(qū)）是永遠(yuǎn)存在的，而不是可選的。

既然分布式系統(tǒng)中故障是無(wú)法避免的，那么處理故障最簡(jiǎn)單的方法便是讓整個(gè)服務(wù)失效，讓應(yīng)用“正確地死去”，但這并不是所有應(yīng)用都能接受。故障轉(zhuǎn)移企圖解決該問(wèn)題，當(dāng)故障發(fā)生時(shí)將其中一個(gè)從庫(kù)提升為主庫(kù)，使新主庫(kù)仍然對(duì)外提供服務(wù)。但是主從數(shù)據(jù)不一致、腦裂等問(wèn)題可能會(huì)讓應(yīng)用“錯(cuò)誤地活著”。代碼托管網(wǎng)站Github在一場(chǎng)事故中，就因?yàn)橐粋€(gè)過(guò)時(shí)的MySQL從庫(kù)被提升為主庫(kù) ，造成MySQL和 Redis中數(shù)據(jù)產(chǎn)生不一致，最后導(dǎo)致一些私有數(shù)據(jù)泄漏到錯(cuò)誤的用戶手中 。為了減輕故障帶來(lái)的影響，我們需要通過(guò)某種手段來(lái)確保數(shù)據(jù)的一致性，而如何驗(yàn)證大規(guī)模分布式系統(tǒng)在故障下依然正確和穩(wěn)定（可靠性）成為了新的難題。

可靠性驗(yàn)證

分布式系統(tǒng)可靠性的驗(yàn)證可以采用形式化規(guī)范來(lái)進(jìn)行，比如TLA+，但是這樣的驗(yàn)證需要大量的特定理論知識(shí)。另一個(gè)方式是通過(guò)測(cè)試來(lái)驗(yàn)證，但普通的單元測(cè)試和集成測(cè)試無(wú)法覆蓋到一些只有在高并發(fā)或者故障發(fā)生時(shí)才會(huì)出現(xiàn)的邊緣情況，這些給分布式系統(tǒng)測(cè)試帶來(lái)了新的挑戰(zhàn)。

混沌工程的出現(xiàn)帶來(lái)了新的驗(yàn)證思路，企業(yè)需要在測(cè)試階段發(fā)現(xiàn)問(wèn)題，通過(guò)“蓄意”引發(fā)故障來(lái)確保容錯(cuò)機(jī)制不斷運(yùn)行并接受考驗(yàn)，從而提高故障自然發(fā)生時(shí)系統(tǒng)能正確處理的信心。出身于SRE的Pavlos Ratis，在自己的GitHub 倉(cāng)庫(kù)awesome-chaos-engineering ，維護(hù)了與混沌工程相關(guān)的書籍、工具、論文、博客、新聞資訊、會(huì)議、論壇和 Twitter 賬號(hào)。另外，故障注入后，除了觀察系統(tǒng)的可用性，還需要保證系統(tǒng)提供的服務(wù)是正確的，也就是系統(tǒng)仍然需要符合預(yù)期的一致性，Jepsen目前被認(rèn)為是工程領(lǐng)域在一致性驗(yàn)證方面的最佳實(shí)踐（下圖展示了Jepsen可驗(yàn)證的一致性模型）。

Jepsen能在特定故障下驗(yàn)證系統(tǒng)是否滿足一致性，在過(guò)去5年里，Kyle Kingsbury已經(jīng)幫助無(wú)數(shù)的早期分布式系統(tǒng)進(jìn)行過(guò)測(cè)試，比如Redis、Etcd、Zookeeper等。Jepsen系統(tǒng)如下圖所示，其由 6 個(gè)節(jié)點(diǎn)組成，一個(gè)控制節(jié)點(diǎn)，五個(gè)DB 節(jié)點(diǎn)。控制節(jié)點(diǎn)可以通過(guò)SSH登錄到DB節(jié)點(diǎn)，通過(guò)控制節(jié)點(diǎn)的控制，可以在DB節(jié)點(diǎn)完成分布式系統(tǒng)的部署，組成一個(gè)待測(cè)試的集群。測(cè)試開(kāi)始后，控制節(jié)點(diǎn)會(huì)創(chuàng)建一組進(jìn)程，進(jìn)程包含了待測(cè)試分布式系統(tǒng)的客戶端。另一個(gè)Generator進(jìn)程產(chǎn)生每個(gè)客戶端執(zhí)行的操作，并將操作應(yīng)用于待測(cè)試的分布式系統(tǒng)。每個(gè)操作的開(kāi)始和結(jié)束以及操作結(jié)果記錄在歷史記錄中。同時(shí)，一個(gè)特殊進(jìn)程N(yùn)emesis將故障引入系統(tǒng)。測(cè)試結(jié)束后，Checker分析歷史記錄是否正確，是否符合一致性。

Jepsen一方面提供了故障注入的手段，能模擬各種各樣的故障，比如網(wǎng)絡(luò)分區(qū)，進(jìn)程崩潰、CPU超載等。另一方面，它提供了各種校驗(yàn)?zāi)Ｐ?，比如Set、Lock、Queue等來(lái)檢測(cè)各種分布式系統(tǒng)在故障下是否仍然滿足所預(yù)期的一致性。通過(guò)Jepsen測(cè)試，能發(fā)現(xiàn)分布式系統(tǒng)在極端故障下的隱藏錯(cuò)誤，從而提高分布式系統(tǒng)的容錯(cuò)能力。因此Jepsen測(cè)試被應(yīng)用到許多分布式數(shù)據(jù)庫(kù)或分布式協(xié)調(diào)服務(wù)集群的可靠性檢測(cè)中，成為驗(yàn)證分布式系統(tǒng)一致性驗(yàn)證的重要手段。而現(xiàn)在我們以基于日志的分布式存儲(chǔ)庫(kù)DLedger和分布式消息隊(duì)列RocketMQ為例，介紹Jepsen測(cè)試在分布式消息系統(tǒng)中的應(yīng)用。

DLedger的Jepsen測(cè)試

DLedger是一個(gè)基于raft的java庫(kù)，用于構(gòu)建高可用性、高持久性、強(qiáng)一致性的commitlog。如下圖所示，DLedger去掉了raft協(xié)議中狀態(tài)機(jī)的部分，但基于Raft協(xié)議保證commitlog是一致的，并且是高可用的。

在對(duì)DLedger進(jìn)行Jepsen測(cè)試之前，首先需要明確DLedger需要滿足怎樣的一致性。在Jepsen測(cè)試中，許多基于raft的分布式應(yīng)用都采用線性一致性對(duì)系統(tǒng)進(jìn)行驗(yàn)證。線性一致性是最強(qiáng)的一致性模型之一，滿足線性一致性的系統(tǒng)，能提供一些唯一性約束的服務(wù)，比如分布式鎖，選主等。但從DLedger的定位來(lái)看，它是一個(gè)Append only的日志系統(tǒng)，并不需要如此嚴(yán)格的一致性，數(shù)據(jù)的最終一致性更加符合我們對(duì)DLedger在故障下的正確性要求。因此采用Jepsen的Set測(cè)試對(duì)DLedger在各種故障下的一致性進(jìn)行檢測(cè)。

Set測(cè)試流程如下圖所示，主要分為兩個(gè)階段。第一階段由不同的客戶端并發(fā)地向待測(cè)試集群添加不同的數(shù)據(jù)，中間會(huì)進(jìn)行故障注入。第二階段，向待測(cè)試的集群進(jìn)行一次最終讀取，獲得讀取的結(jié)果集。最后驗(yàn)證每一個(gè)成功添加的元素都在最終結(jié)果集中，并且最終的結(jié)果集也僅包含企圖添加的元素。

在實(shí)際測(cè)試中，我們開(kāi)啟30個(gè)客戶端進(jìn)程并發(fā)地向待測(cè)試的DLedger集群添加連續(xù)不重復(fù)的數(shù)字，中間會(huì)引入特定故障，比如非對(duì)稱網(wǎng)絡(luò)分區(qū)，隨機(jī)殺死節(jié)點(diǎn)等。故障引入的間隔時(shí)間是30s，即30s正常運(yùn)行，30s故障注入，一直循環(huán)，整個(gè)階段一共持續(xù)600s。并發(fā)寫階段結(jié)束以后，執(zhí)行最終的讀取，獲得結(jié)果集并進(jìn)行校驗(yàn)。

故障注入方面，我們測(cè)試以下幾種故障注入：

• partition-random-node和partition-random-halves故障是模擬常見(jiàn)的對(duì)稱網(wǎng)絡(luò)分區(qū)。

• kill-random-processes和crash-random-nodes故障是模擬進(jìn)程崩潰，節(jié)點(diǎn)崩潰的情況。

• hammer-time故障是模擬一些慢節(jié)點(diǎn)的情況，比如發(fā)生Full GC、OOM等。

• bridge和partition-majorities-ring模擬比較極端的非對(duì)稱網(wǎng)絡(luò)分區(qū)。

我們以隨機(jī)網(wǎng)絡(luò)分區(qū)故障partition-random-halves為例，分析測(cè)試結(jié)果。在測(cè)試完成后，日志中會(huì)出現(xiàn)如下圖所示的結(jié)果：

可以看到測(cè)試過(guò)程中30個(gè)客戶端一共發(fā)送了167354個(gè)數(shù)據(jù)（attempt-count），add成功返回167108個(gè)數(shù)據(jù)（acknowledged-count），實(shí)際成功添加167113個(gè)數(shù)據(jù)（ok-count），有5個(gè)由于請(qǐng)求超時(shí)或者多數(shù)認(rèn)證超時(shí)導(dǎo)致無(wú)法確定是否添加成功，但卻出現(xiàn)在最終讀取結(jié)果集中的數(shù)據(jù)（recovered-count）。由于lost-count=0并且unexpected-count=0，因此最終一致性驗(yàn)證結(jié)果是通過(guò)的。 以圖表的形式更好分析DLedger集群在測(cè)試過(guò)程中的表現(xiàn)情況。客戶端對(duì)DLedger集群每一次操作的時(shí)延如下圖所示。

其中藍(lán)色框表示數(shù)據(jù)添加成功，紅色框表示數(shù)據(jù)添加失敗，黃色框表示不確定是否數(shù)據(jù)添加成功，圖中灰色部分表示故障注入的時(shí)間段?？梢钥闯鲆恍┕收献⑷霑r(shí)間段造成了集群短暫的不可用，一些故障時(shí)間段則沒(méi)有，這是合理的。由于是隨機(jī)網(wǎng)絡(luò)分區(qū)，所以只有當(dāng)前l(fā)eader被隔離到少數(shù)節(jié)點(diǎn)區(qū)域才會(huì)造成集群重新選舉，但即使造成集群重新選舉，在較短時(shí)間內(nèi)，DLedger集群也會(huì)恢復(fù)可用性。此外，可以看到由于DLedger對(duì)對(duì)稱網(wǎng)絡(luò)分區(qū)有較好的容錯(cuò)設(shè)計(jì)，每次故障恢復(fù)后，集群不會(huì)發(fā)生重新選舉。

下圖展示了DLedger在測(cè)試過(guò)程中時(shí)延百分位點(diǎn)圖。

可以看到除了在一些故障引入后造成集群重新選舉的時(shí)間段，時(shí)延升高，在其他的時(shí)間段，Dledger集群表現(xiàn)穩(wěn)定，95%的數(shù)據(jù)添加延遲在5ms以下，99%的數(shù)據(jù)添加延遲在10ms以下。DLedger在隨機(jī)對(duì)稱網(wǎng)絡(luò)分區(qū)故障注入下，表現(xiàn)穩(wěn)定，符合預(yù)期。

除了隨機(jī)對(duì)稱網(wǎng)絡(luò)分區(qū)，DLedger在其他5種故障注入下也均通過(guò)了Set測(cè)試的一致性驗(yàn)證，證明了DLedger對(duì)網(wǎng)絡(luò)分區(qū)，進(jìn)程、節(jié)點(diǎn)崩潰等故障的容錯(cuò)能力。

RocketMQ的Jepsen測(cè)試

Apache RocketMQ是一個(gè)具有低延遲、高性能、高可靠性和靈活可擴(kuò)展性的分布式消息隊(duì)列。RocketMQ從4.5.0版本之后支持DLedger方式部署，使單組broker具有故障轉(zhuǎn)移能力，具有更好的可用性和可靠性。現(xiàn)在我們用Jepsen來(lái)檢測(cè)RocketMQ DLedger部署模式的容錯(cuò)能力。

首先依舊需要明確RocketMQ在故障下需要滿足怎樣的一致性。Jepsen為分布式系統(tǒng)提供了total-queue的測(cè)試，total-queue測(cè)試需要系統(tǒng)滿足入隊(duì)的數(shù)據(jù)必須出隊(duì)，也就是消息的傳輸必須滿足at-least-once。這符合我們對(duì)RocketMQ在故障下正確性要求，因此采用total-queue對(duì)RocketMQ進(jìn)行Jepsen測(cè)試。

total-queue測(cè)試如下圖所示，主要分為兩個(gè)階段。第一階段客戶端進(jìn)程并發(fā)地向集群隨機(jī)調(diào)用入隊(duì)和出隊(duì)操作，入隊(duì)和出隊(duì)操作比例各占一半，中間會(huì)注入故障。第二階段，為了保證每一個(gè)數(shù)據(jù)都出隊(duì)，客戶端進(jìn)程調(diào)用drain操作，抽干隊(duì)列。

在實(shí)際的測(cè)試過(guò)程中，我們開(kāi)啟4個(gè)客戶端進(jìn)程并發(fā)地向待測(cè)試的RocketMQ集群進(jìn)行入隊(duì)和出隊(duì)操作，中間會(huì)引入特定故障。故障注入間隔時(shí)間是200s，整個(gè)階段一共持續(xù)1小時(shí)。第一階段結(jié)束以后，客戶端執(zhí)行drain操作，抽干隊(duì)列。

依舊采用上文所述的六種故障注入進(jìn)行測(cè)試，以隨機(jī)殺死節(jié)點(diǎn)故障為例來(lái)分析測(cè)試結(jié)果（為了保證殺死節(jié)點(diǎn)個(gè)數(shù)不會(huì)導(dǎo)致整個(gè)集群不可用，代碼保證每次故障注入只殺死少數(shù)個(gè)節(jié)點(diǎn)），測(cè)試完成后，出現(xiàn)如下圖所示結(jié)果:

可以看到測(cè)試過(guò)程中30個(gè)客戶端一共試圖入隊(duì)65947個(gè)數(shù)據(jù)（attempt-count），入隊(duì)成功返回64390個(gè)數(shù)據(jù)（acknowledged-count），實(shí)際成功入隊(duì)64390個(gè)數(shù)據(jù)（ok-count），無(wú)重復(fù)出隊(duì)的數(shù)據(jù)，因此故障下的一致性驗(yàn)證是通過(guò)的。

我們以圖表形式更好的分析故障下RocketMQ的表現(xiàn)。下圖是客戶端對(duì)RocketMQ集群每一次操作的時(shí)延圖。

其中紅色小三角形表示入隊(duì)失敗，如果一段時(shí)間內(nèi)存在大量的紅色小三角形則表示該時(shí)間段系統(tǒng)不可用，從圖中可以發(fā)現(xiàn)在故障注入（灰色區(qū)域）初期存在一些系統(tǒng)不可用的時(shí)間段，這是故障引發(fā)集群重新選舉造成的，一段時(shí)間后集群仍能恢復(fù)可用性。但是可以發(fā)現(xiàn)在故障恢復(fù)后，也存在系統(tǒng)不可用的時(shí)間段，這并不符合預(yù)期。

通過(guò)日志排查發(fā)現(xiàn)，故障恢復(fù)后集群不可用的時(shí)間幾乎都在30秒左右，這正是broker向nameserver的注冊(cè)間隔。進(jìn)一步排查發(fā)現(xiàn)，這段時(shí)間內(nèi)nameserver中master broker路由信息出現(xiàn)了丟失。原來(lái)在故障恢復(fù)后，被殺死的broker進(jìn)程進(jìn)行重啟，此時(shí)默認(rèn)brokerId為零，在brokerId被修改之前，broker向nameserver進(jìn)行注冊(cè)，從而覆蓋了原本master broker路由信息，造成集群在該段時(shí)間內(nèi)不可用。對(duì)該問(wèn)題進(jìn)行修復(fù)并重新進(jìn)行Jepsen測(cè)試，重新測(cè)試的時(shí)延圖如下圖所示。

重新測(cè)試的結(jié)果表明問(wèn)題已經(jīng)被修復(fù)，故障恢復(fù)后不存在不可用的時(shí)間段。通過(guò)Jepsen測(cè)試，我們發(fā)現(xiàn)了RocketMQ DLedger部署模式在故障注入下可用性方面的問(wèn)題，并從代碼上進(jìn)行了優(yōu)化，貢獻(xiàn)給RocketMQ社區(qū)。我們也檢測(cè)了其他故障注入下RocketMQ的表現(xiàn)情況，均通過(guò)了total-queue測(cè)試的一致性驗(yàn)證。

Jepsen測(cè)試的一些思考

以DLedger和RocketMQ為例，我們利用Jepsen對(duì)分布式消息系統(tǒng)進(jìn)行了故障下的一致性驗(yàn)證。在測(cè)試過(guò)程中，也發(fā)現(xiàn)了Jepsen框架存在的一些缺陷。

Jepsen測(cè)試無(wú)法長(zhǎng)時(shí)間運(yùn)行。Jepsen測(cè)試長(zhǎng)時(shí)間運(yùn)行會(huì)產(chǎn)生大量的數(shù)據(jù)，這導(dǎo)致其校驗(yàn)階段出現(xiàn)OOM，但在實(shí)際場(chǎng)景中，許多深藏的bug需要長(zhǎng)時(shí)間的壓力測(cè)試、故障模擬才能發(fā)現(xiàn)，同時(shí)系統(tǒng)的穩(wěn)定性也需要長(zhǎng)時(shí)間的運(yùn)行才能被驗(yàn)證。

Jepsen測(cè)試提供的模型還無(wú)法完全覆蓋到特定領(lǐng)域。比如在分布式消息領(lǐng)域，Jepsen僅提供了queue和total-queue的測(cè)試，來(lái)驗(yàn)證消息系統(tǒng)在故障下是否會(huì)出現(xiàn)消息丟失，消息重復(fù)。但是對(duì)于分布式消息隊(duì)列重要的分區(qū)順序性、全局順序性、重平衡算法的有效性并未覆蓋到。

分布式消息標(biāo)準(zhǔn)openmessaging社區(qū)也試圖解決這些問(wèn)題，從而提供消息領(lǐng)域更加完備的可靠性驗(yàn)證。DLedger的Jepsen測(cè)試代碼也已經(jīng)放到openmessaging的openmessaging-dledger-jepsen倉(cāng)庫(kù)下，并提供了Docker啟動(dòng)模式，方便用戶能快速地在單臺(tái)機(jī)器上進(jìn)行測(cè)試。

故障所引發(fā)的錯(cuò)誤代價(jià)非常大，電商網(wǎng)站的中斷會(huì)導(dǎo)致收入和聲譽(yù)的巨大損失，云廠商提供的系統(tǒng)發(fā)生宕機(jī)或故障時(shí)，會(huì)給用戶或他們的用戶帶來(lái)沉痛的代價(jià)。如何讓分布式系統(tǒng)在困境(硬件故障、軟件故障、人為錯(cuò)誤)中仍可正確完成功能，并能達(dá)到期望的性能水準(zhǔn)，這不僅要從算法設(shè)計(jì)和代碼實(shí)現(xiàn)上解決，還需要利用分布式系統(tǒng)測(cè)試工具提前模擬各種故障，從失敗中找到深層的問(wèn)題，提高系統(tǒng)的容錯(cuò)能力。這樣才能在意外真的發(fā)生時(shí)，將意外的損失降到最低。

感謝各位的閱讀，以上就是“DLedger的Jepsen測(cè)試方法是什么”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)DLedger的Jepsen測(cè)試方法是什么這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

新聞名稱：DLedger的Jepsen測(cè)試方法是什么-創(chuàng)新互聯(lián)
文章出自：http://muchs.cn/article6/cdisig.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計(jì)、App設(shè)計(jì)、定制網(wǎng)站、網(wǎng)站排名、全網(wǎng)營(yíng)銷推廣、小程序開(kāi)發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)