• kafka屬于消息引擎系統(tǒng)缎讼， 主要用于系統(tǒng)間傳輸消息澎语， 可以做到系統(tǒng)業(yè)務(wù)上的解耦， 緩沖系統(tǒng)上下游瞬時(shí)突發(fā)流量萍膛，使其更平滑（削峰填谷）吭服。

kafka系統(tǒng)里各種概念

• 消息：Record。Kafka 是消息引擎嘛蝗罗，這里的消息就是指 Kafka 處理的主要對(duì)象艇棕。
• 主題：Topic。主題是承載消息的邏輯容器串塑，在實(shí)際使用中多用來(lái)區(qū)分具體的業(yè)務(wù)沼琉。
• 分區(qū)：Partition。一個(gè)有序不變的消息序列桩匪。每個(gè)主題下可以有多個(gè)分區(qū)打瘪。
• 消息位移：Offset。表示分區(qū)中每條消息的位置信息傻昙，是一個(gè)單調(diào)遞增且不變的值闺骚。
• 副本：Replica。Kafka 中同一條消息能夠被拷貝到多個(gè)地方以提供數(shù)據(jù)冗余屋匕，這些地方就是所謂的副本葛碧。副本還分為領(lǐng)導(dǎo)者副本和追隨者副本，各自有不同的角色劃分过吻。副本是在分區(qū)層級(jí)下的进泼，即每個(gè)分區(qū)可配置多個(gè)副本實(shí)現(xiàn)高可用。
• 生產(chǎn)者：Producer纤虽。向主題發(fā)布新消息的應(yīng)用程序乳绕。
• 消費(fèi)者：Consumer。從主題訂閱新消息的應(yīng)用程序逼纸。
• 消費(fèi)者位移：Consumer Offset洋措。表征消費(fèi)者消費(fèi)進(jìn)度，每個(gè)消費(fèi)者都有自己的消費(fèi)者位移杰刽。
• 消費(fèi)者組：Consumer Group菠发。多個(gè)消費(fèi)者實(shí)例共同組成的一個(gè)組，同時(shí)消費(fèi)多個(gè)分區(qū)以實(shí)現(xiàn)高吞吐贺嫂。
• 重平衡：Rebalance滓鸠。消費(fèi)者組內(nèi)某個(gè)消費(fèi)者實(shí)例掛掉后，其他消費(fèi)者實(shí)例自動(dòng)重新分配訂閱主題分區(qū)的過(guò)程第喳。Rebalance 是 Kafka 消費(fèi)者端實(shí)現(xiàn)高可用的重要手段糜俗。

• kafka的各種概念如下圖所示：
  kafka相關(guān)概念圖
  
  

  重點(diǎn)： kafka里的副本針對(duì)的是分區(qū)來(lái)做的， 副本不提供對(duì)外的服務(wù)，只記錄消息數(shù)據(jù)悠抹，kafka通過(guò)對(duì)topic分區(qū)來(lái)實(shí)現(xiàn)消息系統(tǒng)的負(fù)載珠月。

其他

kafka版本

生產(chǎn)者

生產(chǎn)者發(fā)送數(shù)據(jù)流程

• 如果想指定生產(chǎn)者發(fā)消息的分區(qū)策略， 可以在生產(chǎn)端配置參數(shù)： partitioner.class楔敌， 對(duì)應(yīng)的class需要實(shí)現(xiàn)： org.apache.kafka.clients.producer.Partitioner 這個(gè)接口啤挎。
• 生產(chǎn)者默認(rèn)的分區(qū)策略是根據(jù)消息指定的key發(fā)送到指定的分區(qū)（這也是生產(chǎn)者保證消息有序性的要點(diǎn)），如果消息沒(méi)有指定key卵凑， 采用的是輪詢策略侵浸。具體可以看 DefaultPartitioner這個(gè)類的實(shí)現(xiàn)
• 為了提高生產(chǎn)者的發(fā)送效率， 在發(fā)送消息的時(shí)候氛谜， 可以對(duì)要發(fā)送的消息做壓縮處理掏觉。配置參數(shù)為： "compression.type"。 啟用壓縮需要在生產(chǎn)端的cpu資源有多余的情況下（一般業(yè)務(wù)系統(tǒng)都是I/O密集型的）值漫。
• kafka發(fā)送的消息澳腹， 在發(fā)送的時(shí)候， 會(huì)把多條消息放在一起杨何， 組成消息集合酱塔，在Broker端存的消息是發(fā)送端發(fā)送的"消息集合"
• 避免在Broker配置compression.type， 防止Broker端配置的compression.type跟生產(chǎn)端配置的不一樣危虱， 如果配置的不一樣羊娃， Broker需要對(duì)消息集合做解壓縮， 讓后用Broker配置的壓縮算法重新壓縮消息埃跷， 對(duì)Broker的性能有極大的影響蕊玷。
• 解壓縮發(fā)生在Consumer端， 壓縮算法在消息集合里弥雹。
• 壓縮算法的對(duì)吧吞吐量方面：LZ4 > Snappy > zstd 和 GZIP垃帅；而在壓縮比方面，zstd > LZ4 > GZIP > Snappy剪勿。
• 發(fā)送消息的時(shí)候贸诚， 一定要用通過(guò)回調(diào)方法驗(yàn)證消息是否發(fā)送成功， 不然發(fā)送端有可能會(huì)有丟消息的風(fēng)險(xiǎn)厕吉。
• 設(shè)置 retries 為一個(gè)較大的值酱固，當(dāng)出現(xiàn)網(wǎng)絡(luò)的瞬時(shí)抖動(dòng)時(shí)，消息發(fā)送可能會(huì)失敗头朱，此時(shí)配置了 retries > 0 的 Producer 能夠自動(dòng)重試消息發(fā)送运悲，避免消息丟失。

生產(chǎn)端TCP連接相關(guān)

• KafkaProducer 實(shí)例創(chuàng)建時(shí)啟動(dòng) Sender 線程髓窜，從而創(chuàng)建與 bootstrap.servers 中所有 Broker 的 TCP 連接扇苞。
• KafkaProducer 實(shí)例首次更新元數(shù)據(jù)信息之后，還會(huì)再次創(chuàng)建與集群中所有 Broker 的 TCP 連接寄纵。
• 如果 Producer 端發(fā)送消息到某臺(tái) Broker 時(shí)發(fā)現(xiàn)沒(méi)有與該 Broker 的 TCP 連接鳖敷，那么也會(huì)立即創(chuàng)建連接。
• 如果設(shè)置 Producer 端 connections.max.idle.ms 參數(shù)大于 0程拭，則步驟 1 中創(chuàng)建的 TCP 連接會(huì)被自動(dòng)關(guān)閉定踱；如果設(shè)置該參數(shù) =-1，那么步驟 1 中創(chuàng)建的 TCP 連接將無(wú)法被關(guān)閉恃鞋，從而成為“僵尸”連接崖媚。

消費(fèi)者

消費(fèi)者總體工作流程

消費(fèi)者初始化流程

消費(fèi)者組消費(fèi)詳細(xì)流程

• Consumer分區(qū)的分配策略是在消費(fèi)端來(lái)處理的， 并非在Broker端做的分配方案恤浪，
• kafka中消費(fèi)者組是一個(gè)很重要的概念畅哑， 消費(fèi)者通過(guò)Group_Id來(lái)標(biāo)識(shí)自己屬于那一個(gè)消費(fèi)者組， 消費(fèi)者組整體消費(fèi)某一個(gè)Topic水由， 每個(gè)分區(qū)只會(huì)有一個(gè)消費(fèi)者組的消費(fèi)者來(lái)消費(fèi)荠呐。
• Consumer端有個(gè)參數(shù)enable.auto.commit，把它設(shè)置成false砂客，并采用手動(dòng)提交位移的方式泥张。
• partition.assignment.strategy：消費(fèi)者分區(qū)分配策略，默認(rèn)策略Range+CooperativeSticky鞠值。Kafka可以同時(shí)使用多個(gè)分區(qū)分配策略媚创。可以選擇的策略包括：Range彤恶、RoundRobin钞钙、Sticky、CooperativeSticky
• 注意消費(fèi)端如果掉線了声离， 或者執(zhí)行的任務(wù)過(guò)程歇竟， 會(huì)導(dǎo)致消費(fèi)端觸發(fā)“重平衡”， 重平衡是很重的操作抵恋， 需要盡量避免
• __consumer_offsets 主題里面采用 key 和 value 的方式存儲(chǔ)數(shù)據(jù)焕议。key 是group.id+topic+分區(qū)號(hào)，value 就是當(dāng)前 offset 的值弧关。每隔一段時(shí)間盅安，kafka 內(nèi)部會(huì)對(duì)這個(gè) topic 進(jìn)行compact，也就是每個(gè) group.id+topic+分區(qū)號(hào)就保留最新數(shù)據(jù)世囊。
• Consumer offset是很重要的别瞭， 可以參考這篇文章： https://blog.csdn.net/warybee/article/details/121990020

Broker端

Zookeeper中存儲(chǔ)的Kafka 信息

• 設(shè)置 unclean.leader.election.enable = false，它控制的是哪些 Broker 有資格競(jìng)選分區(qū)的 Leader株憾。如果一個(gè) Broker 落后原先的 Leader 太多蝙寨，那么它一旦成為新的 Leader晒衩，必然會(huì)造成消息的丟失。故一般都要將該參數(shù)設(shè)置成 false墙歪，即不允許這種情況的發(fā)生听系。
• 設(shè)置 replication.factor >= 3， 最好將消息多保存幾份虹菲，畢竟目前防止消息丟失的主要機(jī)制就是冗余
• 設(shè)置 min.insync.replicas > 1靠胜， 控制的是消息至少要被寫(xiě)入到多少個(gè)副本才算是“已提交”。設(shè)置成大于 1 可以提升消息持久性毕源。在實(shí)際環(huán)境中千萬(wàn)不要使用默認(rèn)值 1浪漠。
• 確保 replication.factor > min.insync.replicas。如果兩者相等霎褐，那么只要有一個(gè)副本掛機(jī)址愿，整個(gè)分區(qū)就無(wú)法正常工作了。我們不僅要改善消息的持久性冻璃，防止數(shù)據(jù)丟失必盖，還要在不降低可用性的基礎(chǔ)上完成。推薦設(shè)置成 replication.factor = min.insync.replicas + 1俱饿。