kafka中丟數據可能性探討和kafka為什么高吞吐量

2019/2/22 星期五

在kafka中為什么高吞吐量是他的優點 見下4點優點
1、創建一個topic時，同時可以指定分區數目，分區數越多，其吞吐量也越大，但是需要的資源也越多，同時也會導致更高的不可用性，kafka在接收到生產者發送的消息之后，會根據均衡策略將消息存儲到不同的分區中。因為每條消息都被append到該Partition中，屬于順序寫磁盤，因此效率非常高（經驗證，順序寫磁盤效率比隨機寫內存還要高，這是Kafka高吞吐率的一個很重要的保證）。

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

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

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

如何保證消息的可靠性傳輸？ //kafka丟數據的可能性

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

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

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

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

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

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

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

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

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

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

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

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

zookeeper在kafka中會記錄哪些信息
1、記錄broker信息 比如有哪些kafka節點
2、記錄了topic的partitions分區信息，poartitions的leader
3、controller注冊信息
4、controller_epoch信息
[zk: 192.168.0.151(CONNECTED) 39] get /kafkagroup/controller_epoch
1 //此值為一個數字,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的時候,數據完全有序的，也就是不同partition之間也是有序的。
1、我們知道當前paritition內部的順序，但是我們不能比較來自不同的兩個partition的順序，這是沒有意義的。partition中的數據是有序的，不同partition間的數據丟失了數據的順序。如果topic有多個partition，消費數據時就不能保證數據的順序。在需要嚴格保證消息的消費順序的場景下，需要將partition數目設為1。
2、對于每一個寫入kafka中的數據，他們會隨機的寫入到當前topic中的某一個partition內，有一個例外，你提供一個key給當前的數據，這個時候，你就可以用當前的key去控制當前數據應該傳入到哪個partition中。

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