第一章、Flink的容錯(cuò)機(jī)制
第二章、Flink核心組件和工作原理
第三章、Flink的恢復(fù)策略
第四章、Flink容錯(cuò)機(jī)制的注意事項(xiàng)
第五章、Flink的容錯(cuò)機(jī)制與其他框架的容錯(cuò)機(jī)制相比較
目錄
第一章、Flink的容錯(cuò)機(jī)制
Ⅰ、Flink的容錯(cuò)機(jī)制
1. 概念：
Ⅱ、?狀態(tài)的一致性：
1.一致性級(jí)別：
2.端到端的狀態(tài)一致性
Ⅲ、Flink容錯(cuò)機(jī)制的配置參數(shù)
1. checkpoint.interval：
2. checkpoint.timeout：
3. checkpoint.max-concurrent-checks：
4. checkpoint.min-pause-between-checkpoints：
5. checkpoint.directory：
6. checkpoint.snapshot-mode：
7. state.backend：
第一章、Flink的容錯(cuò)機(jī)制
Ⅰ、Flink的容錯(cuò)機(jī)制
1. 概念：
Flink的容錯(cuò)機(jī)制是確保數(shù)據(jù)流應(yīng)用程序在出現(xiàn)故障時(shí)能夠恢復(fù)一致狀態(tài)的關(guān)鍵機(jī)制。這種機(jī)制通過創(chuàng)建分布式數(shù)據(jù)流和操作符狀態(tài)的一致快照來實(shí)現(xiàn)，這被稱為檢查點(diǎn)（Checkpoint）。
-
當(dāng)系統(tǒng)遇到故障，例如機(jī)器故障、網(wǎng)絡(luò)故障或軟件故障時(shí)，
Flink會(huì)回退到最后一個(gè)成功的檢查點(diǎn)，然后重新啟動(dòng)所有的算子。這樣可以確保即使在故障發(fā)生后，應(yīng)用程序的狀態(tài)也只會(huì)反映數(shù)據(jù)流中的每個(gè)記錄一次，實(shí)現(xiàn)精確一次（exactly-once）的語義。-
在有狀態(tài)的流處理中，如果任務(wù)繼續(xù)處理新數(shù)據(jù)，并不需要“之前的計(jì)算結(jié)果”，而是需要任務(wù)“之前的狀態(tài)”。因此，
Flink選擇了將之前某個(gè)時(shí)間點(diǎn)所有的狀態(tài)保存下來，這份“存檔”就是所謂的“檢查點(diǎn)”（checkpoint）。 -
當(dāng)遇到故障重啟的時(shí)候，可以從檢查點(diǎn)中“讀檔”，恢復(fù)出之前的狀態(tài)，這樣就可以回到當(dāng)時(shí)保存的一刻接著處理數(shù)據(jù)。檢查點(diǎn)是
Flink容錯(cuò)機(jī)制的核心。 -
這種機(jī)制的好處在于，它能夠確保在故障發(fā)生后，應(yīng)用程序的狀態(tài)不會(huì)包含任何重復(fù)或遺漏的處理結(jié)果，從而保證了數(shù)據(jù)處理的準(zhǔn)確性和一致性。這對(duì)于需要處理大量數(shù)據(jù)的應(yīng)用程序來說非常重要，因?yàn)樗梢员苊庖驗(yàn)閿?shù)據(jù)重復(fù)處理或遺漏處理而導(dǎo)致的錯(cuò)誤結(jié)果或數(shù)據(jù)不一致性。
-
-
此外，
Flink還提供了異步屏障快照（Asynchronous Barrier Snapshots）技術(shù)，這是一種輕量級(jí)的快照技術(shù)，可以以低成本備份DAG（有向無環(huán)圖）或DCG（有向有環(huán)圖）計(jì)算作業(yè)的狀態(tài)。這使得計(jì)算作業(yè)可以頻繁進(jìn)行快照并且不會(huì)對(duì)性能產(chǎn)生明顯影響。
總的來說，
Flink的容錯(cuò)機(jī)制能夠確保在遇到故障時(shí)，數(shù)據(jù)流應(yīng)用程序的狀態(tài)最終將恢復(fù)到一致狀態(tài)。這需要將狀態(tài)存儲(chǔ)在可配置的位置（例如主節(jié)點(diǎn)或HDFS上），并且在程序失敗時(shí)，Flink會(huì)停止分布式數(shù)據(jù)流，然后重新啟動(dòng)算子并重置輸入流到相應(yīng)的狀態(tài)快照位置。
Ⅱ、?狀態(tài)的一致性：
當(dāng)在分布式系統(tǒng)中引入狀態(tài)時(shí)，自然也引入了一致性問題。
一致性實(shí)際上是"正確性級(jí)別"的另一種說法，也就是說在成功處理故障并恢復(fù)之后得到的結(jié)果，與沒有發(fā)生任何故障時(shí)得到的結(jié)果相比，前者到底有多正確？
舉例來說，假設(shè)要對(duì)最近一小時(shí)登錄的用戶計(jì)數(shù)。在系統(tǒng)經(jīng)歷故障之后，計(jì)數(shù)結(jié)果是多少？如果有偏差，是有漏掉的計(jì)數(shù)還是重復(fù)計(jì)數(shù)
1.一致性級(jí)別：
在流處理中，一致性可以分為3個(gè)級(jí)別:
-
at-most-once(最多一次):
這其實(shí)是沒有正確性保障的委婉說法——故障發(fā)生之后，計(jì)數(shù)結(jié)果可能丟失。
-
at-least-once(至少一次):
這表示計(jì)數(shù)結(jié)果可能大于正確值，但絕不會(huì)小于正確值。也就是說，計(jì)數(shù)程序在發(fā)生故障后可能多算，但是絕不會(huì)少算。
-
exactly-once(嚴(yán)格一次):
這指的是系統(tǒng)保證在發(fā)生故障后得到的計(jì)數(shù)結(jié)果與正確值一致.既不多算也不少算
曾經(jīng)，at-least-once非常流行。第一代流處理器(如Storm和Samza)剛問世時(shí)只保證at-least-once，原因有二:
-
保證exactly-once的系統(tǒng)實(shí)現(xiàn)起來更復(fù)雜。這在基礎(chǔ)架構(gòu)層(決定什么代表正確，以及exactly-once的范圍是什么)和實(shí)現(xiàn)層都很有挑戰(zhàn)性
-
流處理系統(tǒng)的早期用戶愿意接受框架的局限性，并在應(yīng)用層想辦法彌補(bǔ)(例如使應(yīng)用程序具有冪等性，或者用批量計(jì)算層再做一遍計(jì)算)。
最先保證exactly-once的系統(tǒng)(Storm Trident和Spark Streaming)在性能和表現(xiàn)力這兩個(gè)方面付出了很大的代價(jià)。為了保證exactly-once，這些系統(tǒng)無法單獨(dú)地對(duì)每條記錄運(yùn)用應(yīng)用邏輯，而是同時(shí)處理多條(一批)記錄，保證對(duì)每一批的處理要么全部成功，要么全部失敗。這就導(dǎo)致在得到結(jié)果前，必須等待一批記錄處理結(jié)束。因此，用戶經(jīng)常不得不使用兩個(gè)流處理框架(一個(gè)用來保證exactly-once，另一個(gè)用來對(duì)每個(gè)元素做低延遲處理)，結(jié)果使基礎(chǔ)設(shè)施更加復(fù)雜。曾經(jīng)，用戶不得不在保證exactly-once與獲得低延遲和效率之間權(quán)衡利弊。Flink避免了這種權(quán)衡。
Flink的一個(gè)重大價(jià)值在于，它既保證了exactly-once，又具有低延遲和高吞吐的處理能力。
從根本上說，F(xiàn)link通過使自身滿足所有需求來避免權(quán)衡，它是業(yè)界的一次意義重大的技術(shù)飛躍。
2.端到端的狀態(tài)一致性
目前我們看到的一致性保證都是由流處理器實(shí)現(xiàn)的，也就是說都是在Flink 流處理器內(nèi)部保證的；而在真實(shí)應(yīng)用中，流處理應(yīng)用除了流處理器以外還包含了數(shù)據(jù)源（例如 Kafka）和輸出到持久化系統(tǒng)。
端到端的一致性保證，意味著結(jié)果的正確性貫穿了整個(gè)流處理應(yīng)用的始終；每一個(gè)組件都保證了它自己的一致性，整個(gè)端到端的一致性級(jí)別取決于所有組件中一致性最弱的組件。
具體劃分如下:
-
source端
需要外部源可重設(shè)數(shù)據(jù)的讀取位置.目前我們使用的Kafka Source具有這種特性: 讀取數(shù)據(jù)的時(shí)候可以指定offset
-
flink內(nèi)部
依賴checkpoint機(jī)制
-
sink端
需要保證從故障恢復(fù)時(shí)，數(shù)據(jù)不會(huì)重復(fù)寫入外部系統(tǒng). 有2種實(shí)現(xiàn)形式:
-
冪等（Idempotent）寫入
所謂冪等操作，是說一個(gè)操作，可以重復(fù)執(zhí)行很多次，但只導(dǎo)致一次結(jié)果更改，也就是說，后面再重復(fù)執(zhí)行就不起作用了。
-
事務(wù)性（Transactional）寫入
需要構(gòu)建事務(wù)來寫入外部系統(tǒng)，構(gòu)建的事務(wù)對(duì)應(yīng)著 checkpoint，等到 checkpoint 真正完成的時(shí)候，才把所有對(duì)應(yīng)的結(jié)果寫入 sink 系統(tǒng)中。對(duì)于事務(wù)性寫入，具體又有兩種實(shí)現(xiàn)方式：預(yù)寫日志（WAL）和兩階段提交（2PC）
-
需要構(gòu)建事務(wù)來寫入外部系統(tǒng)，構(gòu)建的事務(wù)對(duì)應(yīng)著 checkpoint，等到 checkpoint 真正完成的時(shí)候，才把所有對(duì)應(yīng)的結(jié)果寫入 sink 系統(tǒng)中。對(duì)于事務(wù)性寫入，具體又有兩種實(shí)現(xiàn)方式：預(yù)寫日志（WAL）和兩階段提交（2PC）
Ⅲ、Flink容錯(cuò)機(jī)制的配置參數(shù)
Flink容錯(cuò)機(jī)制的配置參數(shù)，如Checkpoint和Savepoint的觸發(fā)頻率、超時(shí)時(shí)間、檢查點(diǎn)間隔等。這些參數(shù)會(huì)影響到容錯(cuò)機(jī)制的性能和恢復(fù)時(shí)間。
1. checkpoint.interval：
設(shè)置Checkpoint的觸發(fā)間隔，單位是毫秒。默認(rèn)情況下，Checkpoint是每1000毫秒（1秒）觸發(fā)一次。
2. checkpoint.timeout：
設(shè)置Checkpoint的超時(shí)時(shí)間，單位是毫秒。如果在超時(shí)時(shí)間內(nèi)，Checkpoint還沒有完成，則會(huì)被取消。默認(rèn)情況下，超時(shí)時(shí)間是10秒。
3. checkpoint.max-concurrent-checks：
設(shè)置同時(shí)進(jìn)行的最大Checkpoint數(shù)量（最大并發(fā)檢查）。默認(rèn)情況下，只有1個(gè)Checkpoint在執(zhí)行。
4. checkpoint.min-pause-between-checkpoints：
設(shè)置兩個(gè)Checkpoint之間的最小暫停時(shí)間，單位是毫秒。這個(gè)參數(shù)可以避免在Checkpoint頻繁觸發(fā)時(shí)對(duì)性能的影響。默認(rèn)情況下，最小暫停時(shí)間是0毫秒。
5. checkpoint.directory：
設(shè)置Checkpoint的持久化存儲(chǔ)目錄。需要確保目錄的可用性和可寫權(quán)限。
6. checkpoint.snapshot-mode：
設(shè)置Snapshot的模式，可以選擇EXACTLY_ONCE或AT_LEAST_ONCE。EXACTLY_ONCE表示每個(gè)數(shù)據(jù)記錄只會(huì)被處理一次，AT_LEAST_ONCE表示每個(gè)數(shù)據(jù)記錄可能會(huì)被處理多次，但最終結(jié)果是一致的。
7. state.backend：
設(shè)置狀態(tài)的后端存儲(chǔ)類型，可以選擇MemoryStateBackend、FsStateBackend等。不同的后端存儲(chǔ)類型有不同的特點(diǎn)和適用場(chǎng)景。
8. state.ttl：文章來源：http://www.zghlxwxcb.cn/news/detail-814814.html
設(shè)置狀態(tài)的存活時(shí)間，單位是毫秒。如果狀態(tài)在存活時(shí)間內(nèi)沒有被訪問，則會(huì)被清除。默認(rèn)情況下，狀態(tài)的存活時(shí)間是0毫秒，表示狀態(tài)永不過期。文章來源地址http://www.zghlxwxcb.cn/news/detail-814814.html
到了這里，關(guān)于大數(shù)據(jù)學(xué)習(xí)之Flink、快速搞懂Flink的容錯(cuò)機(jī)制?。。〉奈恼戮徒榻B完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
