柚子快報(bào)激活碼778899分享：kafka簡述

http://yzkb.51969.com/

前言

? 在大數(shù)據(jù)高并發(fā)場景下，當(dāng)系統(tǒng)中出現(xiàn)“生產(chǎn)“和“消費(fèi)“的速度或穩(wěn)定性等因素不一致的時(shí)候，就需要消息隊(duì)列，作為抽象層，彌合雙方的差異。一般選型是Kafka、RocketMQ，這源于這些中間件的高吞吐、可擴(kuò)展以及可靠性。

? 另外企業(yè)中離線業(yè)務(wù)場景實(shí)時(shí)業(yè)務(wù)場景都需要使用到kafka，Kafka具備數(shù)據(jù)的計(jì)算能力和存儲能力，但是兩個(gè)能力相對（MR/SPARK，HDFS）較弱，Kafka角色的角色與hbase比較像，層級關(guān)系比較多。

消息隊(duì)列

? 是一種應(yīng)用間的通信方式，消息發(fā)送后可以立即返回，由消息系統(tǒng)來確保信息的可靠專遞，消息發(fā)布者只管把消息發(fā)布到MQ中而不管誰來取，消息使用者只管從MQ中取消息而不管誰發(fā)布的，這樣發(fā)布者和使用者都不用知道對方的存在。

消息隊(duì)列的應(yīng)用場景

消息隊(duì)列在實(shí)際應(yīng)用中包括如下四個(gè)場景：

應(yīng)用耦合：多應(yīng)用間通過消息隊(duì)列對同一消息進(jìn)行處理，避免調(diào)用接口失敗導(dǎo)致整個(gè)過程失??；

異步處理：多應(yīng)用對消息隊(duì)列中同一消息進(jìn)行處理，應(yīng)用間并發(fā)處理消息，相比串行處理，減少處理時(shí)間；

限流削峰：廣泛應(yīng)用于秒殺或搶購活動中，避免流量過大導(dǎo)致應(yīng)用系統(tǒng)掛掉的情況；

消息驅(qū)動的系統(tǒng)：系統(tǒng)分為消息隊(duì)列、消息生產(chǎn)者、消息消費(fèi)者，生產(chǎn)者負(fù)責(zé)產(chǎn)生消息，消費(fèi)者(可能有多個(gè))負(fù)責(zé)對消息進(jìn)行處理；

消息隊(duì)列的兩種模式

1）點(diǎn)對點(diǎn)模式

? 點(diǎn)對點(diǎn)模式下包括三個(gè)角色： 消息發(fā)送者 (生產(chǎn)者)、 接收者（消費(fèi)者）

? 消息發(fā)送者生產(chǎn)消息發(fā)送到queue中，然后消息接收者從queue中取出并且消費(fèi)消息。消息被消費(fèi)以后，queue中不再有存儲，所以消息接收者不可能消費(fèi)到已經(jīng)被消費(fèi)的消息。

特點(diǎn)：

每個(gè)消息只有一個(gè)接收者（Consumer）(即一旦被消費(fèi)，消息就不再在消息隊(duì)列中)；

? 發(fā)送者和接收者間沒有依賴性，發(fā)送者發(fā)送消息之后，不管有沒有接收者在運(yùn)行，都不會影響到發(fā)送者下次發(fā)送消息；

? 接收者在成功接收消息之后需向隊(duì)列應(yīng)答成功，以便消息隊(duì)列刪除當(dāng)前接收的消息；

2）發(fā)布/訂閱模式

? 發(fā)布/訂閱模式下包括三個(gè)角色： 角色主題（Topic）、 發(fā)布者(Publisher)、訂閱者(Subscriber)

? 發(fā)布者將消息發(fā)送到Topic，系統(tǒng)將這些消息傳遞給多個(gè)訂閱者。

特點(diǎn)：

? 每個(gè)消息可以有多個(gè)訂閱者；

? 發(fā)布者和訂閱者之間有時(shí)間上的依賴性。針對某個(gè)主題（Topic）的訂閱者，它必須創(chuàng)建一個(gè)訂閱者之后，才能消費(fèi)發(fā)布者的消息。

? 為了消費(fèi)消息，訂閱者需要提前訂閱該角色主題，并保持在線運(yùn)行；

介紹

? **kafka是一個(gè)分布式，分區(qū)的，多副本的，多訂閱者的消息發(fā)布訂閱系統(tǒng)（分布式MQ系統(tǒng)）?；趜ookeeper協(xié)調(diào)的分布式消息系統(tǒng)，它的最大的特性就是可以實(shí)時(shí)的處理大量數(shù)據(jù)以滿足各種需求場景：比如基于hadoop的批處理系統(tǒng)、低延遲的實(shí)時(shí)系統(tǒng)、Storm/Spark流式處理引擎，web/nginx日志、搜索日志、監(jiān)控日志、訪問日志，消息服務(wù)等等。**用scala語言編寫，Linkedin于2010年貢獻(xiàn)給了Apache基金會并成為頂級開源項(xiàng)目。

? kafka適合離線和在線消息消費(fèi)。kafka構(gòu)建在zookeeper同步服務(wù)之上。它與apache和spark非常好的集成，應(yīng)用于實(shí)時(shí)流式數(shù)據(jù)分析。

好處

1、可靠性：分布式的，分區(qū)，復(fù)制和容錯(cuò)。

2、可擴(kuò)展性：kafka消息傳遞系統(tǒng)輕松縮放，無需停機(jī)。

3、耐用性：kafka使用分布式提交日志，這意味著消息會盡可能快速的保存在磁盤上，因此它是持久的。

4、性能：kafka對于發(fā)布和定于消息都具有高吞吐量。即使存儲了許多TB的消息，他也爆出穩(wěn)定的性能。 kafka非?？欤罕ＷC零停機(jī)和零數(shù)據(jù)丟失。

使用場景

**1）日志收集：**一個(gè)公司可以用Kafka收集各種服務(wù)的log，通過kafka以統(tǒng)一接口服務(wù)的方式開放給各種consumer，例如hadoop、Hbase、Solr等。

**2）消息系統(tǒng)：**解耦和生產(chǎn)者和消費(fèi)者、緩存消息等。

**3）用戶活動跟蹤：**Kafka經(jīng)常被用來記錄web用戶或者app用戶的各種活動，如瀏覽網(wǎng)頁、搜索、點(diǎn)擊等活動，這些活動信息被各個(gè)服務(wù)器發(fā)布到kafka的topic中，訂閱者通過訂閱這些topic來做實(shí)時(shí)的監(jiān)控分析，或者裝載到hadoop、數(shù)據(jù)倉庫中做離線分析和挖掘。

**4）運(yùn)營指標(biāo)：**Kafka也經(jīng)常用來記錄運(yùn)營監(jiān)控?cái)?shù)據(jù)。包括收集各種分布式應(yīng)用的數(shù)據(jù)，生產(chǎn)各種操作的集中反饋，比如報(bào)警和報(bào)告。

**5）流式框架：**從主題中讀取數(shù)據(jù)，對其進(jìn)行處理，并將處理后的數(shù)據(jù)寫入新的主題，供用戶和應(yīng)用程序使用，kafka的強(qiáng)耐久性在流處理的上下文中也非常的有用。

基本概念

? kafka是一個(gè)分布式的，分區(qū)的消息(官方稱之為commit log)服務(wù)。它提供一個(gè)消息系統(tǒng)應(yīng)該具備的功能，但是確有著獨(dú)特的設(shè)計(jì)。

? 從宏觀層面上看，Producer通過網(wǎng)絡(luò)發(fā)送消息到Kafka集群，然后Consumer來進(jìn)行消費(fèi)。服務(wù)端(brokers)和客戶端(producer、consumer)之間通信通過TCP協(xié)議來完成。

名稱解釋Broker消息中間件處理節(jié)點(diǎn)，一個(gè)Kafka節(jié)點(diǎn)就是一個(gè)broker，一個(gè)或者多個(gè)Broker可以組成一個(gè)Kafka集群TopicKafka根據(jù)topic對消息進(jìn)行歸類，發(fā)布到Kafka集群的每條消息都需要指定一個(gè)topicProducer消息生產(chǎn)者，向Broker發(fā)送消息的客戶端Consumer消息消費(fèi)者，從Broker讀取消息的客戶端ConsumerGroup每個(gè)Consumer屬于一個(gè)特定的Consumer Group，一條消息可以被多個(gè)不同的Consumer Group消費(fèi)，但是一個(gè)Consumer Group中只能有一個(gè)Consumer能夠消費(fèi)該消息Partition物理上的概念，一個(gè)topic可以分為多個(gè)partition，每個(gè)partition內(nèi)部消息是有序的

基本使用（原生API）

1、創(chuàng)建主題

【1】創(chuàng)建一個(gè)名字為“test”的Topic，這個(gè)topic只有一個(gè)partition，并且備份因子也設(shè)置為1：

bin/kafka-topics.sh --create --zookeeper 192.168.65.60:2181 --replication-factor 1 --partitions 1 --topic test

【2】通過以下命令來查看kafka中目前存在的topic

bin/kafka-topics.sh --list --zookeeper 192.168.65.60:2181

【3】除了通過手工的方式創(chuàng)建Topic，當(dāng)producer發(fā)布一個(gè)消息到某個(gè)指定的Topic，如果Topic不存在，就自動創(chuàng)建。所以如果發(fā)送錯(cuò)了Topic，那么就需要創(chuàng)建對應(yīng)的消費(fèi)者來消費(fèi)掉發(fā)送錯(cuò)誤的消息。

【4】刪除主題

bin/kafka-topics.sh --delete --topic test --zookeeper 192.168.65.60:2181

2、發(fā)送消息

? kafka自帶了一個(gè)producer命令客戶端，可以從本地文件中讀取內(nèi)容，也可以以命令行中直接輸入內(nèi)容，并將這些內(nèi)容以消息的形式發(fā)送到kafka集群中。在默認(rèn)情況下，每一個(gè)行會被當(dāng)做成一個(gè)獨(dú)立的消息。

? 示例：運(yùn)行發(fā)布消息的腳本，然后在命令中輸入要發(fā)送的消息的內(nèi)容：

//指定往哪個(gè)broker（也就是服務(wù)器）上發(fā)消息

bin/kafka-console-producer.sh --broker-list 192.168.65.60:9092 --topic test

>this is a msg

>this is a another msg

3、消費(fèi)消息

? 【1】對于consumer，kafka同樣也攜帶了一個(gè)命令行客戶端，會將獲取到內(nèi)容在命令中進(jìn)行輸出，默認(rèn)是消費(fèi)最新的消息：

bin/kafka-console-consumer.sh --bootstrap-server 192.168.65.60:9092 --topic test

【2】想要消費(fèi)之前的消息可以通過–from-beginning參數(shù)指定，如下命令：

//這里便凸顯了與傳統(tǒng)消息中間件的不同，消費(fèi)完，消息依舊保留（默認(rèn)保留在磁盤一周）

bin/kafka-console-consumer.sh --bootstrap-server 192.168.65.60:9092 --from-beginning --topic test

【3】通過不同的終端窗口來運(yùn)行以上的命令，你將會看到在producer終端輸入的內(nèi)容，很快就會在consumer的終端窗口上顯示出來。

【4】所有的命令都有一些附加的選項(xiàng)；當(dāng)我們不攜帶任何參數(shù)運(yùn)行命令的時(shí)候，將會顯示出這個(gè)命令的詳細(xì)用法

執(zhí)行bin/kafka-console-consumer.sh 命令顯示所有的可選參數(shù)

4、消費(fèi)消息類型分析

1）單播消費(fèi)

單播消費(fèi)是一條消息只能被一個(gè)消費(fèi)組內(nèi)的某一個(gè)消費(fèi)者消費(fèi)。

2）多播消費(fèi)

多播消費(fèi)是一條消息可以被不同組內(nèi)的某一個(gè)消費(fèi)者消費(fèi)。

設(shè)計(jì)原理分析

Kafka核心總控制器Controller

? 在Kafka集群中會有一個(gè)或者多個(gè)broker，其中有一個(gè)broker會被選舉為控制器（Kafka Controller），它負(fù)責(zé)管理整個(gè)集群中所有分區(qū)和副本的狀態(tài)。

? 1）當(dāng)某個(gè)分區(qū)的leader副本出現(xiàn)故障時(shí)，由控制器負(fù)責(zé)為該分區(qū)選舉新的leader副本。

? 2）當(dāng)檢測到某個(gè)分區(qū)的ISR集合發(fā)生變化時(shí)，由控制器負(fù)責(zé)通知所有broker更新其元數(shù)據(jù)信息。

? 3）當(dāng)使用kafka-topics.sh腳本為某個(gè)topic增加分區(qū)數(shù)量時(shí)，同樣還是由控制器負(fù)責(zé)讓新分區(qū)被其他節(jié)點(diǎn)感知到。

Controller選舉機(jī)制

【1】在kafka集群啟動的時(shí)候，會自動選舉一臺broker作為controller來管理整個(gè)集群，選舉的過程是集群中每個(gè)broker都會嘗試在zookeeper上創(chuàng)建一個(gè) /controller 臨時(shí)節(jié)點(diǎn)，zookeeper會保證有且僅有一個(gè)broker能創(chuàng)建成功，這個(gè)broker就會成為集群的總控器controller。

【2】當(dāng)這個(gè)controller角色的broker宕機(jī)了，此時(shí)zookeeper臨時(shí)節(jié)點(diǎn)會消失，集群里其他broker會一直監(jiān)聽這個(gè)臨時(shí)節(jié)點(diǎn)，發(fā)現(xiàn)臨時(shí)節(jié)點(diǎn)消失了，就競爭再次創(chuàng)建臨時(shí)節(jié)點(diǎn)。

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

? **1）監(jiān)聽broker相關(guān)的變化。**為Zookeeper中的/brokers/ids/節(jié)點(diǎn)添加BrokerChangeListener，用來處理broker增減的變化。

? **2）監(jiān)聽topic相關(guān)的變化。**為Zookeeper中的/brokers/topics節(jié)點(diǎn)添加TopicChangeListener，用來處理topic增減的變化；為Zookeeper中的/admin/delete_topics節(jié)點(diǎn)添加TopicDeletionListener，用來處理刪除topic的動作。 ? **3）從Zookeeper中讀取獲取當(dāng)前所有與topic、partition以及broker有關(guān)的信息并進(jìn)行相應(yīng)的管理。**對于所有topic所對應(yīng)的Zookeeper中的/brokers/topics/[topic]節(jié)點(diǎn)添加PartitionModificationsListener，用來監(jiān)聽topic中的分區(qū)分配變化。 ? 4）更新集群的元數(shù)據(jù)信息，同步到其他普通的broker節(jié)點(diǎn)中。

Partition副本選舉Leader機(jī)制

controller感知到分區(qū)leader所在的broker掛了(controller監(jiān)聽了很多zk節(jié)點(diǎn)可以感知到broker存活)，controller會從ISR列表(參數(shù)unclean.leader.election.enable=false的前提下)里挑第一個(gè)broker作為leader(第一個(gè)broker最先放進(jìn)ISR列表，可能是同步數(shù)據(jù)最多的副本)【這種會阻塞直到ISR列表有數(shù)據(jù)】，

? 如果參數(shù)unclean.leader.election.enable為true，代表在ISR列表里所有副本都掛了的時(shí)候可以在ISR列表以外的副本中選leader，這種設(shè)置，可以提高可用性，但是選出的新leader有可能數(shù)據(jù)少很多?！酒鋵?shí)就是知道/broker/ids/下面的數(shù)據(jù)沒了】

副本進(jìn)入ISR列表有兩個(gè)條件：

1）副本節(jié)點(diǎn)不能產(chǎn)生分區(qū)，必須能與zookeeper保持會話以及跟leader副本網(wǎng)絡(luò)連通

2）副本能復(fù)制leader上的所有寫操作，并且不能落后太多。(與leader副本同步滯后的副本，是由 replica.lag.time.max.ms 配置決定的，超過這個(gè)時(shí)間都沒有跟leader同步過的一次的副本會被移出ISR列表)

消費(fèi)者消費(fèi)消息的offset記錄機(jī)制

每個(gè)consumer會定期將自己消費(fèi)分區(qū)的offset提交給kafka內(nèi)部topic：__consumer_offsets，提交過去的時(shí)候，key是consumerGroupId+topic+分區(qū)號，value就是當(dāng)前offset的值，kafka會定期清理topic里的消息，最后就保留最新的那條數(shù)據(jù)。【相當(dāng)于記錄了這個(gè)消費(fèi)組在這個(gè)topic的某分區(qū)上消費(fèi)到了哪】

由于consumer_offsets可能會接收高并發(fā)的請求，kafka默認(rèn)給其分配50個(gè)分區(qū)(可以通過offsets.topic.num.partitions設(shè)置)，這樣可以通過加機(jī)器的方式抗大并發(fā)。

? 選出consumer消費(fèi)的offset要提交到consumer_offsets的哪個(gè)分區(qū)公式：hash(consumerGroupId) % consumer_offsets主題的分區(qū)數(shù)

消費(fèi)者Rebalance機(jī)制（再平衡機(jī)制）

**rebalance就是指如果消費(fèi)組里的消費(fèi)者數(shù)量有變化或消費(fèi)的分區(qū)數(shù)有變化，kafka會重新分配消費(fèi)者消費(fèi)分區(qū)的關(guān)系。**比如consumer group中某個(gè)消費(fèi)者掛了，此時(shí)會自動把分配給他的分區(qū)交給其他的消費(fèi)者，如果他又重啟了，那么又會把一些分區(qū)重新交還給他。

注意：

? 1）rebalance只針對subscribe這種不指定分區(qū)消費(fèi)的情況，如果通過assign這種消費(fèi)方式指定了分區(qū)，kafka不會進(jìn)行rebanlance。

? **2）rebalance過程中，消費(fèi)者無法從kafka消費(fèi)消息。**這對kafka的TPS會有影響，如果kafka集群內(nèi)節(jié)點(diǎn)較多，比如數(shù)百個(gè)，那重平衡可能會耗時(shí)極多，所以應(yīng)盡量避免在系統(tǒng)高峰期的重平衡發(fā)生。

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

1.消費(fèi)組里的consumer增加或減少了

2.動態(tài)給topic增加了分區(qū)

3.消費(fèi)組訂閱了更多的topic

消費(fèi)者Rebalance分區(qū)分配策略：

rebalance的策略：range、round-robin、sticky。

Kafka 提供了消費(fèi)者客戶端參數(shù)partition.assignment.strategy 來設(shè)置消費(fèi)者與訂閱主題之間的分區(qū)分配策略。默認(rèn)情況為range分配策略。

假設(shè)一個(gè)主題有10個(gè)分區(qū)(0-9)，現(xiàn)在有三個(gè)consumer消費(fèi)：

1）range策略就是按照分區(qū)序號排序，比如分區(qū)03給一個(gè)consumer，分區(qū)46給一個(gè)consumer，分區(qū)7~9給一個(gè)consumer。

? 假設(shè) n＝分區(qū)數(shù)／消費(fèi)者數(shù)量 = 3， m＝分區(qū)數(shù)%消費(fèi)者數(shù)量 = 1，那么前 m 個(gè)消費(fèi)者每個(gè)分配 n+1 個(gè)分區(qū)，后面的（消費(fèi)者數(shù)量－m ）個(gè)消費(fèi)者每個(gè)分配 n 個(gè)分區(qū)。

2）round-robin策略就是輪詢分配，比如分區(qū)0、3、6、9給一個(gè)consumer，分區(qū)1、4、7給一個(gè)consumer，分區(qū)2、5、8給一個(gè)consumer。

3）sticky策略初始時(shí)分配策略與round-robin類似，但是在rebalance的時(shí)候，需要保證如下兩個(gè)原則。1）分區(qū)的分配要盡可能均勻 。2）分區(qū)的分配盡可能與上次分配的保持相同。

Rebalance過程

? 當(dāng)有消費(fèi)者加入消費(fèi)組時(shí)，消費(fèi)者、消費(fèi)組及組協(xié)調(diào)器之間會經(jīng)歷以下幾個(gè)階段。

1）選擇組協(xié)調(diào)器

? consumer group中的每個(gè)consumer啟動時(shí)會向kafka集群中的某個(gè)節(jié)點(diǎn)發(fā)送 FindCoordinatorRequest 請求來查找對應(yīng)的組協(xié)調(diào)器GroupCoordinator，并跟其建立網(wǎng)絡(luò)連接。

? 組協(xié)調(diào)器GroupCoordinator：每個(gè)consumer group都會選擇一個(gè)broker作為自己的組協(xié)調(diào)器coordinator，負(fù)責(zé)監(jiān)控這個(gè)消費(fèi)組里的所有消費(fèi)者的心跳，以及判斷是否宕機(jī)，然后開啟消費(fèi)者rebalance。

2）加入消費(fèi)組JOIN GROUP

在成功找到消費(fèi)組所對應(yīng)的 GroupCoordinator 之后就進(jìn)入加入消費(fèi)組的階段，在此階段的消費(fèi)者會向 GroupCoordinator 發(fā)送 JoinGroupRequest 請求，并處理響應(yīng)。

? GroupCoordinator 從一個(gè)consumer group中選擇第一個(gè)加入group的consumer作為leader(消費(fèi)組協(xié)調(diào)器)，把consumer group情況發(fā)送給這個(gè)leader，接著這個(gè)leader會負(fù)責(zé)制定分區(qū)方案。

3）（ SYNC GROUP)

consumer leader通過給GroupCoordinator發(fā)送SyncGroupRequest，接著GroupCoordinator就把分區(qū)方案下發(fā)給各個(gè)consumer【心跳的時(shí)候】，他們會根據(jù)指定分區(qū)的leader broker進(jìn)行網(wǎng)絡(luò)連接以及消息消費(fèi)。

producer發(fā)布消息機(jī)制剖析

producer 采用 push 模式將消息發(fā)布到 broker，每條消息都被 append 到 patition 中，屬于順序?qū)懘疟P（順序?qū)懘疟P效率比隨機(jī)寫內(nèi)存要高，保障 kafka 吞吐率）。存儲分區(qū)會根據(jù)分區(qū)算法選擇將其存儲到哪一個(gè) partition。

路由機(jī)制為：

1）指定了 patition，則直接使用；

2）未指定 patition 但指定 key，通過對 key 的 value 進(jìn)行hash 選出一個(gè) patition

3）patition 和 key 都未指定，使用輪詢選出一個(gè) patition。

寫入流程

1）producer 先從 zookeeper 的 “/brokers/…/state” 節(jié)點(diǎn)找到該 partition 的 leader

2）producer 將消息發(fā)送給該 leader

3）leader 將消息寫入本地 log

4）followers 從 leader pull 消息，寫入本地 log 后 向leader 發(fā)送 ACK

5）leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset） 并向 producer 發(fā)送 ACK

集群消費(fèi)

? partitions分布在kafka集群中不同的broker上，kafka集群支持配置partition備份的數(shù)量。針對每個(gè)partition，都有一個(gè)broker起到“l(fā)eader”的作用，其他的broker作為“follwers”的作用。

? leader來負(fù)責(zé)處理所有關(guān)于這個(gè)partition的讀寫請求，而followers被動復(fù)制leader的結(jié)果，不提供讀寫(主要是為了保證多副本數(shù)據(jù)與消費(fèi)的一致性)。如果這個(gè)leader失效了，其中的一個(gè)follower通過選舉成為新的leader。

Producers

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

Consumers

? 傳統(tǒng)的消息傳遞模式有2種：隊(duì)列( queue) 和（publish-subscribe）。Kafka基于這2種模式提供了一種consumer的抽象概念：consumer group。

? 通常一個(gè)topic會有幾個(gè)consumer group，每個(gè)consumer group都是一個(gè)邏輯上的訂閱者（ logical subscriber ）。每個(gè)consumer group由多個(gè)consumer instance組成，從而達(dá)到可擴(kuò)展和容災(zāi)的功能。

其他

消息回溯消費(fèi)的機(jī)制是怎么實(shí)現(xiàn)的？

因?yàn)閗afka的消息存儲在log文件里面，而且對應(yīng)的還會有index與timeindex（可以加快對于消息的檢索），根據(jù)設(shè)置給予的offset可以快速定位到是哪個(gè)log文件，因?yàn)槲募褪莖ffset偏移值?？焖倌贸鰯?shù)據(jù)就可以進(jìn)行消費(fèi)了。此外根據(jù)時(shí)間回溯也是一樣不過量會更大一點(diǎn)。

如果新的消費(fèi)組訂閱已存在的topic，那么是重新開始消費(fèi)么？

**默認(rèn)是將當(dāng)前topoc的最后offset傳給消費(fèi)組，作為其已消費(fèi)的記錄。**所以若是需要從頭消費(fèi)，則要設(shè)置為props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, “earliest”)。這個(gè)消費(fèi)組如果是已經(jīng)存在的，那么這個(gè)參數(shù)其實(shí)不會變動已有的offset。默認(rèn)處理大數(shù)據(jù)量的應(yīng)該采用latest，業(yè)務(wù)場景則用earliest。

日志分段存儲

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

? Kafka Broker 有一個(gè)參數(shù)，log.segment.bytes，限定了每個(gè)日志段文件的大小，最大就是 1GB。

? 一個(gè)日志段文件滿了，就自動開一個(gè)新的日志段文件來寫入，避免單個(gè)文件過大，影響文件的讀寫性能，這個(gè)過程叫做 log rolling，正在被寫入的那個(gè)日志段文件，叫做 active log segment。

總結(jié)

后續(xù)再次補(bǔ)充…

柚子快報(bào)激活碼778899分享：kafka簡述

http://yzkb.51969.com/

好文鏈接