官方文檔：https://kafka.apache.org/24/documentation.html#brokerconfigs

1.Kafka適用場景

日志收集：一個公司可以用Kafka收集各種服務的log，通過kafka以統(tǒng)一接口服務的方式開放給各種consumer馆里，例如hadoop、Hbase启搂、Solr等碘梢。

消息系統(tǒng)：解耦和生產者和消費者蜈块、緩存消息等。

用戶活動跟蹤：Kafka經常被用來記錄web用戶或者app用戶的各種活動这嚣，如瀏覽網頁、搜索塞俱、點擊等活動姐帚，這些活動信息被各個服務器發(fā)布到kafka的topic中，然后訂閱者通過訂閱這些topic來做實時的監(jiān)控分析障涯，或者裝載到hadoop罐旗、數(shù)據(jù)倉庫中做離線分析和挖掘。

運營指標：Kafka也經常用來記錄運營監(jiān)控數(shù)據(jù)唯蝶。包括收集各種分布式應用的數(shù)據(jù)九秀，生產各種操作的集中反饋，比如報警和報告粘我。

2.Kafka基本概念

3.生產者

生產者將消息發(fā)送到topic中去鼓蜒，同時負責選擇將message發(fā)送到topic的哪一個partition中。通過round-robin做簡單的負載均衡征字。也可以根據(jù)消息中的某一個關鍵字來進行區(qū)分都弹。通常第二種方式使用的更多。

1）寫入方式
producer 采用 push 模式將消息發(fā)布到 broker匙姜，每條消息都被 append 到 patition 中畅厢，屬于順序寫磁盤（順序寫磁盤效率比隨機寫內存要高，保障 kafka 吞吐率）搁料。

2）消息路由
producer 發(fā)送消息到 broker 時或详，會根據(jù)分區(qū)算法選擇將其存儲到哪一個 partition。其路由機制為：

• 指定了 patition郭计，則直接使用；
• 未指定 patition 但指定 key椒振，通過對 key 的 value 進行hash 選出一個 patition
• patition 和 key 都未指定昭伸，使用輪詢選出一個 patition。

3）寫入流程

• producer 先從 zookeeper 的 "/brokers/.../state" 節(jié)點找到該 partition 的 leader
• producer 將消息發(fā)送給該 leader
• leader 將消息寫入本地 log
• followers 從 leader pull 消息澎迎，寫入本地 log 后 向leader 發(fā)送 ACK
• leader 收到所有 ISR 中的 replica 的 ACK 后庐杨，增加 HW（high watermark，最后 commit 的 offset） 并向 producer 發(fā)送 ACK

4.Broker

4.1 Topic

可以理解Topic是一個類別的名稱夹供，同類消息發(fā)送到同一個Topic下面灵份。對于每一個Topic，下面可以有多個分區(qū)(Partition)日志文件：

• Partition是一個有序的message序列哮洽，這些message按順序添加到一個叫做commit log的文件中填渠。每個partition中的消息都有一個唯一的編號，稱之為offset，用來唯一標示某個分區(qū)中的message氛什。
• 每個partition莺葫，都對應一個commit log文件。一個partition中的message的offset都是唯一的枪眉，但是不同的partition中的message的offset可能是相同的捺檬。
• kafka一般不會刪除消息，不管這些消息有沒有被消費贸铜。只會根據(jù)配置的日志保留時間(log.retention.hours)確認消息多久被刪除堡纬，默認保留最近一周的日志消息。kafka的性能與保留的消息數(shù)據(jù)量大小沒有關系蒿秦，因此保存大量的數(shù)據(jù)消息日志信息不會有什么影響隐轩。
• 每個consumer是基于自己在commit log中的消費進度(offset)來進行工作的。在kafka中渤早，消費offset由consumer自己來維護职车；一般情況下我們按照順序逐條消費commit log中的消息，當然我可以通過指定offset來重復消費某些消息鹊杖，或者跳過某些消息悴灵。
• 這意味kafka中的consumer對集群的影響是非常小的，添加一個或者減少一個consumer骂蓖，對于集群或者其他consumer來說积瞒，都是沒有影響的，因為每個consumer維護各自的消費offset登下。

Topic的情況：

• leader節(jié)點負責給定partition的所有讀寫請求茫孔，同一個主題不同分區(qū)leader副本一般不一樣(為了容災)
• replicas 表示某個partition在哪幾個broker上存在備份。不管這個幾點是不是”leader“被芳，甚至這個節(jié)點掛了缰贝，也會列出。
• isr 是replicas的一個子集畔濒，它只列出當前還存活著的剩晴，并且已同步備份了該partition的節(jié)點。

4.2 HW與LEO詳解

HW俗稱高水位侵状，HighWatermark的縮寫赞弥，取一個partition對應的ISR中最小的LEO(log-end-offset)作為HW，consumer最多只能消費到HW所在的位置趣兄。另外每個replica都有HW,leader和follower各自負責更新自己的HW的狀態(tài)绽左。對于leader新寫入的消息，consumer不能立刻消費艇潭，leader會等待該消息被所有ISR中的replicas同步后更新HW拼窥，此時消息才能被consumer消費戏蔑。這樣就保證了如果leader所在的broker失效，該消息仍然可以從新選舉的leader中獲取闯团。對于來自內部broker的讀取請求辛臊，沒有HW的限制。

由此可見房交，Kafka的復制機制既不是完全的同步復制彻舰，也不是單純的異步復制。事實上候味，同步復制要求所有能工作的follower都復制完刃唤，這條消息才會被commit，這種復制方式極大的影響了吞吐率白群。而異步復制方式下尚胞，follower異步的從leader復制數(shù)據(jù)，數(shù)據(jù)只要被leader寫入log就被認為已經commit帜慢，這種情況下如果follower都還沒有復制完笼裳，落后于leader時，突然leader宕機粱玲，則會丟失數(shù)據(jù)躬柬。而Kafka的這種使用ISR的方式則很好的均衡了確保數(shù)據(jù)不丟失以及吞吐率。

4.3 日志分段存儲

Kafka 一個分區(qū)的消息數(shù)據(jù)對應存儲在一個文件夾下抽减，以topic名稱+分區(qū)號命名允青，消息在分區(qū)內是分段(segment)存儲，每個段的消息都存儲在不一樣的log文件里卵沉，這種特性方便old segment file快速被刪除颠锉，kafka規(guī)定了一個段位的 log 文件最大為 1G，做這個限制目的是為了方便把 log 文件加載到內存去操作

# 部分消息的offset索引文件史汗，kafka每次往分區(qū)發(fā)4K(可配置)消息就會記錄一條當前消息的offset到index文件琼掠，
# 如果要定位消息的offset會先在這個文件里快速定位，再去log文件里找具體消息
00000000000000000000.index
# 消息存儲文件淹办，主要存offset和消息體
00000000000000000000.log
# 消息的發(fā)送時間索引文件眉枕，kafka每次往分區(qū)發(fā)4K(可配置)消息就會記錄一條當前消息的發(fā)送時間戳與對應的offset到timeindex文件，
# 如果需要按照時間來定位消息的offset怜森，會先在這個文件里查找
00000000000000000000.timeindex

00000000000005367851.index
00000000000005367851.log
00000000000005367851.timeindex

00000000000009936472.index
00000000000009936472.log
00000000000009936472.timeindex

這個 9936472 之類的數(shù)字，就是代表了這個日志段文件里包含的起始 Offset谤牡，也就說明這個分區(qū)里至少都寫入了接近 1000 萬條數(shù)據(jù)了副硅。

Kafka Broker 有一個參數(shù)，log.segment.bytes翅萤，限定了每個日志段文件的大小恐疲，最大就是 1GB腊满。

一個日志段文件滿了，就自動開一個新的日志段文件來寫入培己，避免單個文件過大碳蛋，影響文件的讀寫性能，這個過程叫做 log rolling省咨，正在被寫入的那個日志段文件肃弟，叫做 active log segment。

4.4 Controller選舉以及副本選舉

Kafka核心總控制器Controller
在Kafka集群中會有一個或者多個broker零蓉，其中有一個broker會被選舉為控制器（Kafka Controller）笤受，它負責管理整個集群中所有分區(qū)和副本的狀態(tài)。

• 當某個分區(qū)的leader副本出現(xiàn)故障時敌蜂，由控制器負責為該分區(qū)選舉新的leader副本箩兽。
• 當檢測到某個分區(qū)的ISR集合發(fā)生變化時，由控制器負責通知所有broker更新其元數(shù)據(jù)信息章喉。
• 當使用kafka-topics.sh腳本為某個topic增加分區(qū)數(shù)量時汗贫，同樣還是由控制器負責讓新分區(qū)被其他節(jié)點感知到。

Controller選舉機制

• 在kafka集群啟動的時候秸脱，會自動選舉一臺broker作為controller來管理整個集群落包，選舉的過程是集群中每個broker都會嘗試在zookeeper上創(chuàng)建一個 /controller 臨時節(jié)點，zookeeper會保證有且僅有一個broker能創(chuàng)建成功撞反，這個broker就會成為集群的總控器controller妥色。
• 當這個controller角色的broker宕機了，此時zookeeper臨時節(jié)點會消失遏片，集群里其他broker會一直監(jiān)聽這個臨時節(jié)點嘹害，發(fā)現(xiàn)臨時節(jié)點消失了，就競爭再次創(chuàng)建臨時節(jié)點吮便，就是我們上面說的選舉機制笔呀，zookeeper又會保證有一個broker成為新的controller。

具備控制器身份的broker需要比其他普通的broker多一份職責髓需，具體細節(jié)如下：

• 監(jiān)聽broker相關的變化许师。為Zookeeper中的/brokers/ids/節(jié)點添加BrokerChangeListener，用來處理broker增減的變化僚匆。
• 監(jiān)聽topic相關的變化微渠。為Zookeeper中的/brokers/topics節(jié)點添加TopicChangeListener，用來處理topic增減的變化咧擂；為Zookeeper中的/admin/delete_topics節(jié)點添加TopicDeletionListener逞盆，用來處理刪除topic的動作。
• 從Zookeeper中讀取獲取當前所有與topic松申、partition以及broker有關的信息并進行相應的管理云芦。對于所有topic所對應的Zookeeper中的/brokers/topics/[topic]節(jié)點添加PartitionModificationsListener俯逾，用來監(jiān)聽topic中的分區(qū)分配變化。
• 更新集群的元數(shù)據(jù)信息舅逸，同步到其他普通的broker節(jié)點中桌肴。

Partition副本選舉Leader機制
controller感知到分區(qū)leader所在的broker掛了(controller監(jiān)聽了很多zk節(jié)點可以感知到broker存活)，controller會從ISR列表(參數(shù)unclean.leader.election.enable=false的前提下)里挑第一個broker作為leader(第一個broker最先放進ISR列表琉历，可能是同步數(shù)據(jù)最多的副本)坠七，如果參數(shù)unclean.leader.election.enable為true，代表在ISR列表里所有副本都掛了的時候可以在ISR列表以外的副本中選leader善已，這種設置灼捂，可以提高可用性，但是選出的新leader有可能數(shù)據(jù)少很多换团。
副本進入ISR列表有兩個條件：

• 副本節(jié)點不能產生分區(qū)悉稠，必須能與zookeeper保持會話以及跟leader副本網絡連通
• 副本能復制leader上的所有寫操作，并且不能落后太多艘包。(與leader副本同步滯后的副本的猛，是由 replica.lag.time.max.ms 配置決定的，超過這個時間都沒有跟leader同步過的一次的副本會被移出ISR列表)

5.消費者

5.1 消費模式

傳統(tǒng)的消息傳遞模式有2種：隊列( queue) 和（publish-subscribe）

• queue模式：多個consumer從服務器中讀取數(shù)據(jù)想虎，消息只會到達一個consumer卦尊。
• publish-subscribe模式：消息會被廣播給所有的consumer。

Kafka基于這2種模式提供了一種consumer的抽象概念：consumer group舌厨。

• queue模式：所有的consumer都位于同一個consumer group 下岂却。
• publish-subscribe模式：所有的consumer都有著自己唯一的consumer group。

5.2 消費順序

消費順序

• 一個partition同一個時刻在一個consumer group中只能有一個consumer instance在消費裙椭，從而保證消費順序躏哩。
• consumer group中的consumer instance的數(shù)量不能比一個Topic中的partition的數(shù)量多，否則揉燃，多出來的consumer消費不到消息扫尺。
• Kafka只在partition的范圍內保證消息消費的局部順序性，不能在同一個topic中的多個partition中保證總的消費順序性炊汤。
• 如果有在總體上保證消費順序的需求正驻，那么我們可以通過將topic的partition數(shù)量設置為1，將consumer group中的consumer instance數(shù)量也設置為1抢腐，但是這樣會影響性能姑曙，所以kafka的順序消費很少用。

5.3 消費者消費消息的offset記錄機制

每個consumer會定期將自己消費分區(qū)的offset提交給kafka內部topic：__consumer_offsets迈倍，提交過去的時候渣磷，key是consumerGroupId+topic+分區(qū)號，value就是當前offset的值授瘦，kafka會定期清理topic里的消息醋界，最后就保留最新的那條數(shù)據(jù)。

因為__consumer_offsets可能會接收高并發(fā)的請求提完，kafka默認給其分配50個分區(qū)(可以通過offsets.topic.num.partitions設置)形纺，這樣可以通過加機器的方式抗大并發(fā)。

通過如下公式可以選出consumer消費的offset要提交到__consumer_offsets的哪個分區(qū)
公式：hash(consumerGroupId) % __consumer_offsets主題的分區(qū)數(shù)

5.4 消費者Rebalance機制

rebalance就是說如果消費組里的消費者數(shù)量有變化或消費的分區(qū)數(shù)有變化徒欣，kafka會重新分配消費者消費分區(qū)的關系逐样。比如consumer group中某個消費者掛了，此時會自動把分配給他的分區(qū)交給其他的消費者打肝，如果他又重啟了脂新，那么又會把一些分區(qū)重新交還給他。

注意：rebalance只針對subscribe這種不指定分區(qū)消費的情況粗梭，如果通過assign這種消費方式指定了分區(qū)争便，kafka不會進行rebanlance。

如下情況可能會觸發(fā)消費者rebalance

• 消費組里的consumer增加或減少了
• 動態(tài)給topic增加了分區(qū)
• 消費組訂閱了更多的topic

rebalance過程中断医，消費者無法從kafka消費消息滞乙，這對kafka的TPS會有影響，如果kafka集群內節(jié)點較多鉴嗤，比如數(shù)百個斩启，那重平衡可能會耗時極多，所以應盡量避免在系統(tǒng)高峰期的重平衡發(fā)生醉锅。

消費者Rebalance分區(qū)分配策略：
主要有三種rebalance的策略：range兔簇、round-robin、sticky硬耍。
Kafka 提供了消費者客戶端參數(shù)partition.assignment.strategy 來設置消費者與訂閱主題之間的分區(qū)分配策略垄琐。默認情況為range分配策略。
假設一個主題有10個分區(qū)(0-9)默垄，現(xiàn)在有三個consumer消費：

• range策略就是按照分區(qū)序號排序此虑，假設 n＝分區(qū)數(shù)／消費者數(shù)量 = 3， m＝分區(qū)數(shù)%消費者數(shù)量 = 1口锭，那么前 m 個消費者每個分配 n+1 個分區(qū)朦前，后面的（消費者數(shù)量－m ）個消費者每個分配 n 個分區(qū)。
  比如分區(qū)0_{3給一個consumer鹃操，分區(qū)4}6給一個consumer棍丐，分區(qū)7~9給一個consumer件蚕。
• round-robin策略就是輪詢分配，比如分區(qū)0、3堤器、6、9給一個consumer，分區(qū)1、4凰荚、7給一個consumer，分區(qū)2褒脯、5便瑟、8給一個consumer
• sticky策略初始時分配策略與round-robin類似，但是在rebalance的時候番川，需要保證如下兩個原則到涂。
  1）分區(qū)的分配要盡可能均勻 。
  2）分區(qū)的分配盡可能與上次分配的保持相同颁督。
  當兩者發(fā)生沖突時践啄，第一個目標優(yōu)先于第二個目標 。這樣可以最大程度維持原來的分區(qū)分配的策略沉御。
  比如對于第一種range情況的分配屿讽，如果第三個consumer掛了，那么重新用sticky策略分配的結果如下：
  consumer1除了原有的0~3嚷节，會再分配一個7
  consumer2除了原有的4~6聂儒，會再分配8和9

第一階段：選擇組協(xié)調器
組協(xié)調器GroupCoordinator：每個consumer group都會選擇一個broker作為自己的組協(xié)調器coordinator，負責監(jiān)控這個消費組里的所有消費者的心跳硫痰，以及判斷是否宕機衩婚，然后開啟消費者rebalance。
consumer group中的每個consumer啟動時會向kafka集群中的某個節(jié)點發(fā)送 FindCoordinatorRequest 請求來查找對應的組協(xié)調器GroupCoordinator效斑，并跟其建立網絡連接非春。
組協(xié)調器選擇方式：
consumer消費的offset要提交到__consumer_offsets的哪個分區(qū)，這個分區(qū)leader對應的broker就是這個consumer group的coordinator

第二階段：加入消費組JOIN GROUP
在成功找到消費組所對應的 GroupCoordinator 之后就進入加入消費組的階段缓屠，在此階段的消費者會向 GroupCoordinator 發(fā)送 JoinGroupRequest 請求奇昙，并處理響應。然后GroupCoordinator 從一個consumer group中選擇第一個加入group的consumer作為leader(消費組協(xié)調器)敌完，把consumer group情況發(fā)送給這個leader储耐，接著這個leader會負責制定分區(qū)方案。

第三階段（ SYNC GROUP)
consumer leader通過給GroupCoordinator發(fā)送SyncGroupRequest滨溉，接著GroupCoordinator就把分區(qū)方案下發(fā)給各個consumer什湘，他們會根據(jù)指定分區(qū)的leader broker進行網絡連接以及消息消費。

6.Zookeeper

7.一些問題及解決方案

1晦攒、消息丟失情況：
消息發(fā)送端：
（1）acks=0： 表示producer不需要等待任何broker確認收到消息的回復闽撤，就可以繼續(xù)發(fā)送下一條消息。性能最高脯颜，但是最容易丟消息哟旗。大數(shù)據(jù)統(tǒng)計報表場景，對性能要求很高，對數(shù)據(jù)丟失不敏感的情況可以用這種闸餐。
（2）acks=1： 至少要等待leader已經成功將數(shù)據(jù)寫入本地log饱亮，但是不需要等待所有follower是否成功寫入。就可以繼續(xù)發(fā)送下一條消息绎巨。這種情況下近尚，如果follower沒有成功備份數(shù)據(jù)，而此時leader又掛掉场勤，則消息會丟失。
（3）acks=-1或all： 這意味著leader需要等待所有備份(min.insync.replicas配置的備份個數(shù))都成功寫入日志歼跟，這種策略會保證只要有一個備份存活就不會丟失數(shù)據(jù)和媳。這是最強的數(shù)據(jù)保證。一般除非是金融級別哈街，或跟錢打交道的場景才會使用這種配置留瞳。當然如果min.insync.replicas配置的是1則也可能丟消息，跟acks=1情況類似骚秦。
消息消費端：
如果消費這邊配置的是自動提交她倘，萬一消費到數(shù)據(jù)還沒處理完，就自動提交offset了作箍，但是此時你consumer直接宕機了硬梁，未處理完的數(shù)據(jù)丟失了，下次也消費不到了胞得。

2荧止、消息重復消費
消息發(fā)送端：
發(fā)送消息如果配置了重試機制，比如網絡抖動時間過長導致發(fā)送端發(fā)送超時阶剑，實際broker可能已經接收到消息跃巡，但發(fā)送方會重新發(fā)送消息
消息消費端：
如果消費這邊配置的是自動提交，剛拉取了一批數(shù)據(jù)處理了一部分牧愁，但還沒來得及提交素邪，服務掛了，下次重啟又會拉取相同的一批數(shù)據(jù)重復處理
一般消費端都是要做消費冪等處理的猪半。

3兔朦、消息亂序
如果發(fā)送端配置了重試機制，kafka不會等之前那條消息完全發(fā)送成功才去發(fā)送下一條消息办龄，這樣可能會出現(xiàn)烘绽，發(fā)送了1，2俐填，3條消息安接，第一條超時了，后面兩條發(fā)送成功，再重試發(fā)送第1條消息盏檐，這時消息在broker端的順序就是2歇式，3，1了
所以胡野，是否一定要配置重試要根據(jù)業(yè)務情況而定材失。也可以用同步發(fā)送的模式去發(fā)消息，當然acks不能設置為0硫豆，這樣也能保證消息發(fā)送的有序龙巨。
kafka保證全鏈路消息順序消費，需要從發(fā)送端開始熊响，將所有有序消息發(fā)送到同一個分區(qū)旨别，然后用一個消費者去消費，但是這種性能比較低汗茄，可以在消費者端接收到消息后將需要保證順序消費的幾條消費發(fā)到內存隊列(可以搞多個)秸弛，一個內存隊列開啟一個線程順序處理消息。

保證消息有序：
1）發(fā)送端：用同步發(fā)送的模式去發(fā)消息洪碳，當然acks不能設置為0递览，這樣也能保證消息發(fā)送的有序。
2）broker端：將所有有序消息發(fā)送到同一個分區(qū)
3）消費端：用一個消費者去消費瞳腌；也可以在消費者端接收到消息后將需要保證順序消費的幾條消息發(fā)到內存隊列(可以搞多個)绞铃，一個內存隊列開啟一個線程順序處理消息。

4纯趋、消息積壓
1）線上有時因為發(fā)送方發(fā)送消息速度過快憎兽，或者消費方處理消息過慢，可能會導致broker積壓大量未消費消息吵冒。
此種情況如果積壓了上百萬未消費消息需要緊急處理纯命，可以修改消費端程序，讓其將收到的消息快速轉發(fā)到其他topic(可以設置很多分區(qū))痹栖，然后再啟動多個消費者同時消費新主題的不同分區(qū)亿汞。
2）由于消息數(shù)據(jù)格式變動或消費者程序有bug，導致消費者一直消費不成功揪阿，也可能導致broker積壓大量未消費消息疗我。
此種情況可以將這些消費不成功的消息轉發(fā)到其它隊列里去(類似死信隊列)，后面再慢慢分析死信隊列里的消息處理問題南捂。

5吴裤、延時隊列
延時隊列存儲的對象是延時消息。所謂的“延時消息”是指消息被發(fā)送以后溺健，并不想讓消費者立刻獲取麦牺，而是等待特定的時間后，消費者才能獲取這個消息進行消費，延時隊列的使用場景有很多剖膳， 比如 ：
1）在訂單系統(tǒng)中魏颓， 一個用戶下單之后通常有 30 分鐘的時間進行支付，如果 30 分鐘之內沒有支付成功吱晒，那么這個訂單將進行異常處理甸饱，這時就可以使用延時隊列來處理這些訂單了。
2）訂單完成1小時后通知用戶進行評價仑濒。

實現(xiàn)思路：發(fā)送延時消息時先把消息按照不同的延遲時間段發(fā)送到指定的隊列中（topic_1s叹话，topic_5s，topic_10s躏精，...topic_2h渣刷，這個一般不能支持任意時間段的延時），然后通過定時器進行輪訓消費這些topic矗烛，查看消息是否到期，如果到期就把這個消息發(fā)送到具體業(yè)務處理的topic中箩溃，隊列中消息越靠前的到期時間越早瞭吃，具體來說就是定時器在一次消費過程中，對消息的發(fā)送時間做判斷涣旨，看下是否延遲到對應時間了歪架，如果到了就轉發(fā)，如果還沒到這一次定時任務就可以提前結束了霹陡。

6和蚪、消息回溯
如果某段時間對已消費消息計算的結果覺得有問題，可能是由于程序bug導致的計算錯誤烹棉，當程序bug修復后攒霹，這時可能需要對之前已消費的消息重新消費，可以指定從多久之前的消息回溯消費浆洗，這種可以用consumer的offsetsForTimes催束、seek等方法指定從某個offset偏移的消息開始消費

7、分區(qū)數(shù)越多吞吐量越高嗎
從壓測結果來看伏社，分區(qū)數(shù)到達某個值吞吐量反而開始下降抠刺，實際上很多事情都會有一個臨界值，當超過這個臨界值之后摘昌，很多原本符合既定邏輯的走向又會變得不同速妖。一般情況分區(qū)數(shù)跟集群機器數(shù)量相當就差不多了。
當然吞吐量的數(shù)值和走勢還會和磁盤聪黎、文件系統(tǒng)罕容、 I/O調度策略等因素相關。

8、消息傳遞保障
at most once(消費者最多收到一次消息杀赢，0--1次)：acks = 0 可以實現(xiàn)烘跺。
at least once(消費者至少收到一次消息，1--多次)：ack = all 可以實現(xiàn)脂崔。
exactly once(消費者剛好收到一次消息)：at least once 加上消費者冪等性可以實現(xiàn)滤淳，還可以用kafka生產者的冪等性來實現(xiàn)。
kafka生產者的冪等性：因為發(fā)送端重試導致的消息重復發(fā)送問題砌左，kafka的冪等性可以保證重復發(fā)送的消息只接收一次脖咐，只需在生產者加上參數(shù) props.put(“enable.idempotence”, true) 即可，默認是false不開啟汇歹。
具體實現(xiàn)原理是屁擅，kafka每次發(fā)送消息會生成PID和Sequence Number，并將這兩個屬性一起發(fā)送給broker产弹，broker會將PID和Sequence Number跟消息綁定一起存起來派歌，下次如果生產者重發(fā)相同消息，broker會檢查PID和Sequence Number痰哨，如果相同不會再接收胶果。
PID：每個新的 Producer 在初始化的時候會被分配一個唯一的 PID，這個PID 對用戶完全是透明的斤斧。生產者如果重啟則會生成新的PID早抠。
Sequence Number：對于每個 PID，該 Producer 發(fā)送到每個 Partition 的數(shù)據(jù)都有對應的序列號撬讽，這些序列號是從0開始單調遞增的蕊连。

9、kafka的事務
Kafka的事務不同于Rocketmq游昼，Rocketmq是保障本地事務(比如數(shù)據(jù)庫)與mq消息發(fā)送的事務一致性甘苍，Kafka的事務主要是保障一次發(fā)送多條消息的事務一致性(要么同時成功要么同時失敗)，一般在kafka的流式計算場景用得多一點酱床，比如羊赵，kafka需要對一個topic里的消息做不同的流式計算處理，處理完分別發(fā)到不同的topic里扇谣，這些topic分別被不同的下游系統(tǒng)消費(比如hbase昧捷，redis，es等)罐寨，這種我們肯定希望系統(tǒng)發(fā)送到多個topic的數(shù)據(jù)保持事務一致性靡挥。

10、kafka高性能的原因

• 磁盤順序讀寫：kafka消息不能修改以及不會從文件中間刪除保證了磁盤順序讀鸯绿，kafka的消息寫入文件都是追加在文件末尾跋破，不會寫入文件中的某個位置(隨機寫)保證了磁盤順序寫簸淀。
• 數(shù)據(jù)傳輸?shù)牧憧截?/li>
• 讀寫數(shù)據(jù)的批量batch處理以及壓縮傳輸

參考

• 圖靈vip課程：https://vip.tulingxueyuan.cn/