kafka中丟數(shù)據(jù)可能性探討和kafka為什么高吞吐量

2019/2/22 星期五

在kafka中為什么高吞吐量是他的優(yōu)點 見下4點優(yōu)點
1、創(chuàng)建一個topic時，同時可以指定分區(qū)數(shù)目，分區(qū)數(shù)越多，其吞吐量也越大，但是需要的資源也越多，同時也會導(dǎo)致更高的不可用性，kafka在接收到生產(chǎn)者發(fā)送的消息之后，會根據(jù)均衡策略將消息存儲到不同的分區(qū)中。因為每條消息都被append到該Partition中，屬于順序?qū)懘疟P，因此效率非常高（經(jīng)驗證，順序?qū)懘疟P效率比隨機寫內(nèi)存還要高，這是Kafka高吞吐率的一個很重要的保證）。

站在用戶的角度思考問題，與客戶深入溝通，找到鳳岡網(wǎng)站設(shè)計與鳳岡網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都網(wǎng)站建設(shè)、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、國際域名空間、雅安服務(wù)器托管、企業(yè)郵箱。業(yè)務(wù)覆蓋鳳岡地區(qū)。

2、我們知道在kafaf中的數(shù)據(jù)不會一直保存著，一般默認(rèn)是存儲2周時間，2周時間之后會刪除數(shù)據(jù)，當(dāng)然這些可以通關(guān)參數(shù)去調(diào)整，
因此Kafka提供兩種策略刪除舊數(shù)據(jù)。一是基于時間，二是基于Partition文件大小。例如可以通過配置$KAFKA_HOME/config/server.properties，讓Kafka刪除一周前的數(shù)據(jù)，也可在Partition文件超過1GB時刪除舊數(shù)據(jù)，
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
log.cleaner.enable=false
那既然刪除數(shù)據(jù)和kafka的性能無關(guān)，怎么刪除數(shù)據(jù)就磁盤策略以及具體的需求有關(guān)。
offset由Consumer控制，因為offet由Consumer控制，所以Kafka broker是無狀態(tài)的，它不需要標(biāo)記哪些消息被哪些消費過，也不需要通過broker去保證同一個Consumer Group只有一個Consumer能消費某一條消息，因此也就不需要鎖機制，這也為Kafka的高吞吐率提供了有力保障。

3、有了Partition后，不同的消息可以并行寫入不同broker的不同Partition里，極大的提高了吞吐率。

4、使用consumer high level api時，同一個topic的一條消息只能被同一個consumer group內(nèi)的一個consumer消費，但多個consumer group可以同時消費這一個消息。

---

如何保證消息的可靠性傳輸？ //kafka丟數(shù)據(jù)的可能性

https://blog.csdn.net/qq_36236890/article/details/81174504 //此鏈接非常的重要

kafka有幾種故障的轉(zhuǎn)移 //參考鏈接為 https://www.cnblogs.com/qingyunzong/p/9004593.html
有這么幾種可能的delivery guarantee：
At most once 　　消息可能會丟，但絕不會重復(fù)傳輸
At least one 　　 消息絕不會丟，但可能會重復(fù)傳輸
Exactly once 　　 每條消息肯定會被傳輸一次且僅傳輸一次，很多時候這是用戶所想要的。

丟數(shù)據(jù)可能性1
當(dāng)Producer向broker發(fā)送消息時，一旦這條消息被commit，因數(shù)replication的存在，它就不會丟。但是如果Producer發(fā)送數(shù)據(jù)給broker后，遇到網(wǎng)絡(luò)問題而造成通信中斷，那Producer就無法判斷該條消息是否已經(jīng)commit。雖然Kafka無法確定網(wǎng)絡(luò)故障期間發(fā)生了什么，但是Producer可以生成一種類似于主鍵的東西，發(fā)生故障時冪等性的重試多次，這樣就做到了Exactly once。
//這一步是Producer生產(chǎn)者到kafka broker過程會出現(xiàn)的消息丟失的可能性和解決方法

丟數(shù)據(jù)可能性2
接下來討論的是消息從broker到Consumer的delivery guarantee語義。（僅針對Kafka consumer high level API）。Consumer在從broker讀取消息后，可以選擇commit，該操作會在Zookeeper中保存該Consumer在該Partition中讀取的消息的offset。該Consumer下一次再讀該Partition時會從下一條開始讀取。
如未commit，下一次讀取的開始位置會跟上一次commit之后的開始位置相同。當(dāng)然可以將Consumer設(shè)置為autocommit//自動提交，即Consumer一旦讀到數(shù)據(jù)立即自動commit。如果只討論這一讀取消息的過程，那Kafka是確保了Exactly once。
但實際使用中應(yīng)用程序并非在Consumer讀取完數(shù)據(jù)就結(jié)束了，而是要進行進一步處理，而數(shù)據(jù)處理與commit的順序在很大程度上決定了消息從broker和consumer的delivery guarantee semantic（交付保證語義）。
//這一步是Consumer消費者到kafka broker過程會出現(xiàn)的消息丟失的可能性和解決方法

Kafka默認(rèn)保證At least once//消息絕不會丟，但可能會重復(fù)傳輸，并且允許通過設(shè)置Producer異步提交來實現(xiàn)At most once。而Exactly once要求與外部存儲系統(tǒng)協(xié)作，幸運的是Kafka提供的offset可以非常直接非常容易得使用這種方式。

生產(chǎn)者傳遞消息到broker過程
1、Producer在發(fā)布消息到某個Partition時，先通過ZooKeeper找到該Partition的Leader，然后無論該Topic的Replication Factor為多少，Producer只將該消息發(fā)送到該Partition的Leader。
2、Leader會將該消息寫入其本地Log。
3、每個Follower都從Leader pull數(shù)據(jù)。這種方式上，F(xiàn)ollower存儲的數(shù)據(jù)順序與Leader保持一致。
4、Follower在收到該消息并寫入其Log后，向Leader發(fā)送ACK。
5、一旦Leader收到了ISR中的所有Replica的ACK，該消息就被認(rèn)為已經(jīng)commit了，
6、Leader將增加HW并且向Producer發(fā)送ACK。

提示：
為了提高性能，每個Follower在接收到數(shù)據(jù)后就立馬向Leader發(fā)送ACK，而非等到數(shù)據(jù)寫入Log中。
注意：
因此，對于已經(jīng)commit的消息，Kafka只能保證它被存于多個Replica的內(nèi)存中，而不能保證它們被持久化到磁盤中，也就不能完全保證異常發(fā)生后該條消息一定能被Consumer消費。Consumer讀消息也是從Leader讀取，只有被commit過的消息才會暴露給Consumer。 //這里就有可能存在丟數(shù)據(jù)的可能性 丟數(shù)據(jù)可能性3

什么是producer的同步模式和異步模式？
同步模式
如果Producer使用同步模式則Producer會在嘗試重新發(fā)送message.send.max.retries（默認(rèn)值為3）次后拋出Exception，用戶可以選擇停止發(fā)送后續(xù)數(shù)據(jù)也可選擇繼續(xù)選擇發(fā)送。而前者會造成數(shù)據(jù)的阻塞，后者會造成本應(yīng)發(fā)往該Broker的數(shù)據(jù)的丟失。
異步模式
如果Producer使用異步模式，則Producer會嘗試重新發(fā)送message.send.max.retries（默認(rèn)值為3）次后記錄該異常并繼續(xù)發(fā)送后續(xù)數(shù)據(jù)，這會造成數(shù)據(jù)丟失并且用戶只能通過日志發(fā)現(xiàn)該問題。同時，Kafka的Producer并未對異步模式提供callback接口。

提示：
kafka是非同步和非異步之間的一種模式（replication）策略，同步模式和異步模式都有很大的可能出現(xiàn)數(shù)據(jù)丟失。
同步：都完成了才可以結(jié)束；異步：丟失數(shù)據(jù)用戶不知道，只能通過日志記錄
Kafka的高可靠性的保障來源于其健壯的副本（replication）策略。

參考鏈接：https://www.cnblogs.com/qingyunzong/p/9004703.html

Leader會跟蹤與其保持同步的Replica列表，該列表稱為ISR（即in-sync Replica）。
Kafka的復(fù)制機制既不是完全的同步復(fù)制，也不是單純的異步復(fù)制。
而Kafka的這種使用ISR的方式則很好的均衡了確保數(shù)據(jù)不丟失以及吞吐率。Follower可以批量的從Leader復(fù)制數(shù)據(jù)，這樣極大的提高復(fù)制性能（批量寫磁盤），極大減少了Follower與Leader的差距。 //批量復(fù)制數(shù)據(jù)方式，防止數(shù)據(jù)丟失1

一條消息只有被ISR里的所有Follower都從Leader復(fù)制過去才會被認(rèn)為已提交。這樣就避免了部分?jǐn)?shù)據(jù)被寫進了Leader，還沒來得及被任何Follower復(fù)制就宕機了，而造成數(shù)據(jù)丟失（Consumer無法消費這些數(shù)據(jù)）。 //防止數(shù)據(jù)丟失2

zookeeper在kafka中會記錄哪些信息
1、記錄broker信息 比如有哪些kafka節(jié)點
2、記錄了topic的partitions分區(qū)信息，poartitions的leader
3、controller注冊信息
4、controller_epoch信息
[zk: 192.168.0.151(CONNECTED) 39] get /kafkagroup/controller_epoch
1 //此值為一個數(shù)字,kafka集群中第一個broker第一次啟動時為1，以后只要集群中center controller中央控制器所在broker變更或掛掉，就會重新選舉新的center controller，每次center controller變更controller_epoch值就會 + 1;
cZxid = 0x1500000049
ctime = Sun Jan 27 16:33:22 CST 2019
mZxid = 0x1500000049
mtime = Sun Jan 27 16:33:22 CST 2019
pZxid = 0x1500000049
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 1
numChildren = 0
5、[zk: 192.168.0.151(CONNECTED) 41] ls /kafkagroup/admin/delete_topics
6、會記錄消費者和消費組信息consumers consumers group

如何保證kafka消費topic的時候,數(shù)據(jù)完全有序的，也就是不同partition之間也是有序的。
1、我們知道當(dāng)前paritition內(nèi)部的順序，但是我們不能比較來自不同的兩個partition的順序，這是沒有意義的。partition中的數(shù)據(jù)是有序的，不同partition間的數(shù)據(jù)丟失了數(shù)據(jù)的順序。如果topic有多個partition，消費數(shù)據(jù)時就不能保證數(shù)據(jù)的順序。在需要嚴(yán)格保證消息的消費順序的場景下，需要將partition數(shù)目設(shè)為1。
2、對于每一個寫入kafka中的數(shù)據(jù)，他們會隨機的寫入到當(dāng)前topic中的某一個partition內(nèi)，有一個例外，你提供一個key給當(dāng)前的數(shù)據(jù)，這個時候，你就可以用當(dāng)前的key去控制當(dāng)前數(shù)據(jù)應(yīng)該傳入到哪個partition中。

kafka默認(rèn)是消費者可以分組（Consumer Group），比如有兩個消費者組A 和B，共同消費一個topic：order_info,A 和B所消費的消息不會重復(fù)
比如order_info 中有100 個消息，每個消息有一個id,編號從0-99，那么，如果A組消費0-49 號，B 組就消費50-99 號
//生產(chǎn)環(huán)境中也可以讓多個consumer共同消費同一個topic中的數(shù)據(jù)？需要設(shè)置調(diào)整
實現(xiàn)方法一：代碼段可以實現(xiàn)
使用Consumer high level API時，同一Topic的一條消息只能被同一個Consumer Group內(nèi)的一個Consumer消費，但多個Consumer Group可同時消費這一消息。
實現(xiàn)方法二：我們可以這樣，把A B兩個消費者分為2個不同的組，不同的消費組可以消費同一個topic的數(shù)據(jù)。

文章標(biāo)題：kafka中丟數(shù)據(jù)可能性探討和kafka為什么高吞吐量
文章轉(zhuǎn)載：http://muchs.cn/article22/picicc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供、軟件開發(fā)、網(wǎng)頁設(shè)計公司、網(wǎng)站設(shè)計、網(wǎng)站營銷、外貿(mào)建站

廣告

聲明：本網(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)