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

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

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

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

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

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

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

可靠性驗證

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

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

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

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

DLedger的Jepsen測試

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

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

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

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

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

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

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

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

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

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

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

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

下圖展示了DLedger在測試過程中時延百分位點圖。

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

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

RocketMQ的Jepsen測試

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

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

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

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

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

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

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

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

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

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

Jepsen測試的一些思考

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

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

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

分布式消息標準openmessaging社區(qū)也試圖解決這些問題，從而提供消息領域更加完備的可靠性驗證。DLedger的Jepsen測試代碼也已經(jīng)放到openmessaging的openmessaging-dledger-jepsen倉庫下，并提供了Docker啟動模式，方便用戶能快速地在單臺機器上進行測試。

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

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

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

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

廣告

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