Kafka零資料丟失的配置方案
這兩年大資料行業發展前景較好,行業工程師薪資高、人才少、競爭壓力小,很多人也因此想要轉型成為大資料工程師,但也正是因為行業新、人才少,很多技術解決方案也是缺少很優質的答案。今天,我給大家詳細剖析一個大資料工程師面試中的高頻面試題——Kafka是如何保證資料零丟失的?
如果要想保證Kafka資料不丟, 要從Kafka的三個地方入手:生產者、服務端和消費者。
生產者
01 / API使用
在生產中Kafka生產者的開發我們都會用非同步呼叫的方式,非同步呼叫方式有如下兩個API:
1)producer.send(msg) 不帶回撥方法2)producer.send(msg,callback) 帶回撥方法 |
記得要使用帶有回撥方法的API,我們可以根據回撥函式得知訊息是否傳送成功,如果傳送失敗了我們要進行異常處理,比如儲存到其他介質來保證訊息不丟。
02 / acks引數設定
acks這個引數有三個值:0,1,-1,但是不同的引數對應的含義不同,那如果我們想要保證資料不丟,acks值應該設定為哪個引數呢?請看下面的表格:
|
| ||
1
|
| ||
-1(all)
|
代表生產者把訊息傳送到服務端,服務端的ISR列表裡所有replica 都寫入成功以後,才會返回成功響應給生產者。假設ISR列表裡面有該分割槽的三個replica(一個leader replica,兩個follower replica),那麼acks=-1就意味著訊息要寫入到leader replica,並且兩個follower replica從leader replica上同步資料成功,服務端才會給生產者傳送訊息傳送成功的響應。 所以ISR列表裡面的replica就非常關鍵。如果我們想要保證資料不丟,那麼acks的值設定為-1,並且還需要保證ISR列表裡面是1個副本以上,具體由哪個引數控制,看下面的服務端的配置。 |
所以acks的值要設定為-1。
03 / 重試次數設定所以acks的值要設定為-1。
為了保證資料不丟,我們儘可能的設定較大的重試次數(引數是retries),如果重試失敗了,對異常進行處理,可以把訊息儲存到另外安全到地方。
服務端
01 / unclean.leader.election.enable
這個引數是控制leader replica出問題了以後follower replica競選leader replica資格的,我們把設定為false,意思就是如果follower replica如果落後leader replica太多就不能參與競選。
02 / replication.factor
這個引數設定的是partition副本的個數,如果我們要想保證資料不丟,這個副本數需要設定成大於1。
03 / min.insync.replicas
這個引數要跟生產者裡的acks引數配合使用,當生產者acks=-1時,服務端的ISR列表裡的所有副本都寫入成功,才會給生產者返回成功的響應。而min.insync.replicas這個引數就是控制ISR列表的,假設min.insync.replicas=1,這就意味著ISR列表裡可以只有一個副本,這個副本就是leader replica,這個時候即使acks設定的是-1,但其實訊息只傳送到leader replica,以後就返回成功的響應了。
因為ISR只有一個副本,我們知道這種情況是有可能會丟資料的,所以min.insync.replicas這個值需要大於1的(如果ISR列表裡面副本的個數小於min.insync.replicas,生產者傳送訊息是失敗的),並且是min.insync.replicas <= replication.factor
消費者
01 / 手動提交offset
消費者是可以自動提交offset的,但是如果是自動提交offset,可能會丟資料,比如消費者每隔3秒提交一次offset,假如偏移量成功提交了,但是資料處理失敗了,這個時候就會丟資料。所以把enable.auto.commit設定成false就行。
當然,我們也只是有限度的保證Kafka資料不丟,因為我們知道Kafka的資料首先是寫到作業系統快取的,假如我們用了上面的配置方案,資料寫入成功了,還沒落到磁碟,但是叢集停電了,這個時候也是會丟資料的!
Kafka 是一種高吞吐量的分散式釋出訂閱訊息系統,它能夠解決和處理的問題還有很多。當然了,要想成為一名合格的大資料工程師,還要具備系統的大資料技術知識體系 ,並熟練使用技術解決不同工作場景中遇到的問題。像Zookeeper、Hadoop、Flume......
更多免費技術資料及影片
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69976011/viewspace-2698091/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Spark Streaming使用Kafka保證資料零丟失SparkKafka
- Spark Streaming和Kafka整合是如何保證資料零丟失SparkKafka
- Kafka重複消費和丟失資料研究Kafka
- kafka 如何保證不重複消費又不丟失資料?Kafka
- 硬碟資料丟失原因和解決方案/資料恢復方法硬碟資料恢復
- Kafka消費者自動提交配置會導致潛在的重複或資料丟失!Kafka
- Android資料庫升級不丟失資料解決方案Android資料庫
- 增量資料丟失的原因分析
- 基於linux系統,fsck後資料丟失的資料恢復方案Linux資料恢復
- 如何找回分割槽丟失的資料
- 增量資料丟失的原因分析(二)
- 增量資料丟失的原因分析(三)
- 資料檔案丟失的恢復
- Vuex資料頁面重新整理丟失問題解決方案Vue
- 09.redis 哨兵主備切換時資料丟失的解決方案Redis
- Oracle Redo丟失恢復方案Oracle
- 硬碟資料丟失如何恢復?硬碟
- 資料檔案損壞、丟失
- 模擬資料檔案丟失
- 分割槽丟失資料恢復資料恢復
- chkdsk 後資料丟失的恢復方法
- 優步是如何用Kafka構建可靠的重試處理保證資料不丟失Kafka
- 儲存互斥失敗導致資料丟失的資料恢復成功案例資料恢復
- 伺服器資料恢復方法-RAID資訊丟失解決方案伺服器資料恢復AI
- TSPITR方式資料庫找回誤操作丟失的資料資料庫
- 華納雲:防止資料庫資料丟失的幾個方法資料庫
- RMAN完全恢復丟失的資料檔案
- 普通資料檔案丟失的恢復方法
- 恢復REDO Log丟失的Oracle資料庫Oracle資料庫
- 資料檔案丟失損壞的恢復--
- session丟失與解決辦法的資料Session
- SQLServer複製到execl丟失資料SQLServer
- Elasticsearch如何保證資料不丟失?Elasticsearch
- dfm檔案資料丟失問題
- 資料檔案丟失如何恢復
- kafka 消費組功能驗證以及消費者資料重複資料丟失問題說明 3Kafka
- 刨根問底: Kafka 到底會不會丟資料?Kafka
- 北亞資料恢復-WINDOWS還原系統後原分割槽丟失的資料恢復方案資料恢復Windows