kafka知識點有哪些呢

1 什么是kafka

Kafka是分布式發(fā)布-訂閱消息系統(tǒng)，它最初是由LinkedIn公司開發(fā)的，之后成為Apache項目的一部分，Kafka是一個分布式，可劃分的，冗余備份的持久性的日志服務，它主要用于處理流式數(shù)據(jù)。

2 為什么要使用 kafka，為什么要使用消息隊列

緩沖和削峰：上游數(shù)據(jù)時有突發(fā)流量，下游可能扛不住，或者下游沒有足夠多的機器來保證冗余，kafka在中間可以起到一個緩沖的作用，把消息暫存在kafka中，下游服務就可以按照自己的節(jié)奏進行慢慢處理。

解耦和擴展性：項目開始的時候，并不能確定具體需求。消息隊列可以作為一個接口層，解耦重要的業(yè)務流程。只需要遵守約定，針對數(shù)據(jù)編程即可獲取擴展能力。

冗余：可以采用一對多的方式，一個生產(chǎn)者發(fā)布消息，可以被多個訂閱topic的服務消費到，供多個毫無關(guān)聯(lián)的業(yè)務使用。

健壯性：消息隊列可以堆積請求，所以消費端業(yè)務即使短時間死掉，也不會影響主要業(yè)務的正常進行。

異步通信：很多時候，用戶不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但并不立即處理它。想向隊列中放入多少消息就放多少，然后在需要的時候再去處理它們。

3.Kafka中的ISR、AR又代表什么？ISR的伸縮又指什么

ISR:In-Sync Replicas 副本同步隊列 AR:Assigned Replicas 所有副本 ISR是由leader維護，follower從leader同步數(shù)據(jù)有一些延遲（包括延遲時間replica.lag.time.max.ms和延遲條數(shù)replica.lag.max.messages兩個維度, 當前最新的版本0.10.x中只支持replica.lag.time.max.ms這個維度），任意一個超過閾值都會把follower剔除出ISR, 存入OSR（Outof-Sync Replicas）列表，新加入的follower也會先存放在OSR中。AR=ISR+OSR。

4.kafka中的broker 是干什么的

broker 是消息的代理，Producers往Brokers里面的指定Topic中寫消息，Consumers從Brokers里面拉取指定Topic的消息，然后進行業(yè)務處理，broker在中間起到一個代理保存消息的中轉(zhuǎn)站。

5.kafka中的 zookeeper 起到什么作用，可以不用zookeeper么

zookeeper 是一個分布式的協(xié)調(diào)組件，早期版本的kafka用zk做meta信息存儲，consumer的消費狀態(tài)，group的管理以及 offset的值?？紤]到zk本身的一些因素以及整個架構(gòu)較大概率存在單點問題，新版本中逐漸弱化了zookeeper的作用。新的consumer使用了kafka內(nèi)部的group coordination協(xié)議，也減少了對zookeeper的依賴，

但是broker依然依賴于ZK，zookeeper 在kafka中還用來選舉controller 和 檢測broker是否存活等等。

6.kafka follower如何與leader同步數(shù)據(jù)

Kafka的復制機制既不是完全的同步復制，也不是單純的異步復制。完全同步復制要求All Alive Follower都復制完，這條消息才會被認為commit，這種復制方式極大的影響了吞吐率。而異步復制方式下，F(xiàn)ollower異步的從Leader復制數(shù)據(jù)，數(shù)據(jù)只要被Leader寫入log就被認為已經(jīng)commit，這種情況下，如果leader掛掉，會丟失數(shù)據(jù)，kafka使用ISR的方式很好的均衡了確保數(shù)據(jù)不丟失以及吞吐率。Follower可以批量的從Leader復制數(shù)據(jù)，而且Leader充分利用磁盤順序讀以及send file(zero copy)機制，這樣極大的提高復制性能，內(nèi)部批量寫磁盤，大幅減少了Follower與Leader的消息量差。

7.什么情況下一個 broker 會從 isr中踢出去

leader會維護一個與其基本保持同步的Replica列表，該列表稱為ISR(in-sync Replica)，每個Partition都會有一個ISR，而且是由leader動態(tài)維護 ，如果一個follower比一個leader落后太多，或者超過一定時間未發(fā)起數(shù)據(jù)復制請求，則leader將其重ISR中移除 。

8.kafka 為什么那么快

Cache Filesystem Cache PageCache緩存

順序?qū)?由于現(xiàn)代的操作系統(tǒng)提供了預讀和寫技術(shù)，磁盤的順序?qū)懘蠖鄶?shù)情況下比隨機寫內(nèi)存還要快。

Zero-copy 零拷技術(shù)減少拷貝次數(shù)

Batching of Messages 批量量處理。合并小的請求，然后以流的方式進行交互，直頂網(wǎng)絡(luò)上限。

Pull 拉模式 使用拉模式進行消息的獲取消費，與消費端處理能力相符。

9.kafka producer如何優(yōu)化打入速度

• 增加線程

• 提高 batch.size

• 增加更多 producer 實例

• 增加 partition 數(shù)

• 設(shè)置 acks=-1 時，如果延遲增大：可以增大 num.replica.fetchers（follower 同步數(shù)據(jù)的線程數(shù)）來調(diào)解；

• 跨數(shù)據(jù)中心的傳輸：增加 socket 緩沖區(qū)設(shè)置以及 OS tcp 緩沖區(qū)設(shè)置。

10.kafka producer 打數(shù)據(jù)，ack  為 0， 1， -1 的時候代表啥， 設(shè)置 -1 的時候，什么情況下，leader 會認為一條消息 commit了

1（默認） 數(shù)據(jù)發(fā)送到Kafka后，經(jīng)過leader成功接收消息的的確認，就算是發(fā)送成功了。在這種情況下，如果leader宕機了，則會丟失數(shù)據(jù)。

0 生產(chǎn)者將數(shù)據(jù)發(fā)送出去就不管了，不去等待任何返回。這種情況下數(shù)據(jù)傳輸效率最高，但是數(shù)據(jù)可靠性確是最低的。

-1 producer需要等待ISR中的所有follower都確認接收到數(shù)據(jù)后才算一次發(fā)送完成，可靠性最高。當ISR中所有Replica都向Leader發(fā)送ACK時，leader才commit，這時候producer才能認為一個請求中的消息都commit了。

11.kafka  unclean 配置代表啥，會對 spark streaming 消費有什么影響

unclean.leader.election.enable為true的話，意味著非ISR集合的broker 也可以參與選舉，這樣有可能就會丟數(shù)據(jù)，spark streaming在消費過程中拿到的 end offset 會突然變小，導致 spark streaming job掛掉。如果unclean.leader.election.enable參數(shù)設(shè)置為true，就有可能發(fā)生數(shù)據(jù)丟失和數(shù)據(jù)不一致的情況，Kafka的可靠性就會降低；而如果unclean.leader.election.enable參數(shù)設(shè)置為false，Kafka的可用性就會降低。

12.如果leader crash時，ISR為空怎么辦

kafka在Broker端提供了一個配置參數(shù)：unclean.leader.election,這個參數(shù)有兩個值：true（默認）：允許不同步副本成為leader，由于不同步副本的消息較為滯后，此時成為leader，可能會出現(xiàn)消息不一致的情況。false：不允許不同步副本成為leader，此時如果發(fā)生ISR列表為空，會一直等待舊leader恢復，降低了可用性。

13.kafka的message格式是什么樣的

一個Kafka的Message由一個固定長度的header和一個變長的消息體body組成

header部分由一個字節(jié)的magic(文件格式)和四個字節(jié)的CRC32(用于判斷body消息體是否正常)構(gòu)成。

當magic的值為1的時候，會在magic和crc32之間多一個字節(jié)的數(shù)據(jù)：attributes(保存一些相關(guān)屬性，比如是否壓縮、壓縮格式等等);如果magic的值為0，那么不存在attributes屬性。body是由N個字節(jié)構(gòu)成的一個消息體，包含了具體的key/value消息

14.kafka中consumer group 是什么概念

同樣是邏輯上的概念，是Kafka實現(xiàn)單播和廣播兩種消息模型的手段。同一個topic的數(shù)據(jù)，會廣播給不同的group；同一個group中的worker，只有一個worker能拿到這個數(shù)據(jù)。換句話說，對于同一個topic，每個group都可以拿到同樣的所有數(shù)據(jù)，但是數(shù)據(jù)進入group后只能被其中的一個worker消費。group內(nèi)的worker可以使用多線程或多進程來實現(xiàn)，也可以將進程分散在多臺機器上，worker的數(shù)量通常不超過partition的數(shù)量，且二者最好保持整數(shù)倍關(guān)系，因為Kafka在設(shè)計時假定了一個partition只能被一個worker消費（同一group內(nèi)）。

15.Kafka中的消息是否會丟失和重復消費？

要確定Kafka的消息是否丟失或重復，從兩個方面分析入手：消息發(fā)送和消息消費。

1、消息發(fā)送

Kafka消息發(fā)送有兩種方式：同步（sync）和異步（async），默認是同步方式，可通過producer.type屬性進行配置。Kafka通過配置request.required.acks屬性來確認消息的生產(chǎn)：

0---表示不進行消息接收是否成功的確認；1---表示當Leader接收成功時確認；-1---表示Leader和Follower都接收成功時確認；

綜上所述，有6種消息生產(chǎn)的情況，下面分情況來分析消息丟失的場景：

（1）acks=0，不和Kafka集群進行消息接收確認，則當網(wǎng)絡(luò)異常、緩沖區(qū)滿了等情況時，消息可能丟失；

（2）acks=1、同步模式下，只有Leader確認接收成功后但掛掉了，副本沒有同步，數(shù)據(jù)可能丟失；

2、消息消費

Kafka消息消費有兩個consumer接口，Low-level API和High-level API：

Low-level API：消費者自己維護offset等值，可以實現(xiàn)對Kafka的完全控制；

High-level API：封裝了對parition和offset的管理，使用簡單；

如果使用高級接口High-level API，可能存在一個問題就是當消息消費者從集群中把消息取出來、并提交了新的消息offset值后，還沒來得及消費就掛掉了，那么下次再消費時之前沒消費成功的消息就“詭異”的消失了；

解決辦法：

針對消息丟失：同步模式下，確認機制設(shè)置為-1，即讓消息寫入Leader和Follower之后再確認消息發(fā)送成功；異步模式下，為防止緩沖區(qū)滿，可以在配置文件設(shè)置不限制阻塞超時時間，當緩沖區(qū)滿時讓生產(chǎn)者一直處于阻塞狀態(tài)；

針對消息重復：將消息的唯一標識保存到外部介質(zhì)中，每次消費時判斷是否處理過即可。

16.為什么Kafka不支持讀寫分離？

在 Kafka 中，生產(chǎn)者寫入消息、消費者讀取消息的操作都是與 leader 副本進行交互的，從 而實現(xiàn)的是一種主寫主讀的生產(chǎn)消費模型。

Kafka 并不支持主寫從讀，因為主寫從讀有 2 個很明 顯的缺點:

(1)數(shù)據(jù)一致性問題。數(shù)據(jù)從主節(jié)點轉(zhuǎn)到從節(jié)點必然會有一個延時的時間窗口，這個時間 窗口會導致主從節(jié)點之間的數(shù)據(jù)不一致。某一時刻，在主節(jié)點和從節(jié)點中 A 數(shù)據(jù)的值都為 X， 之后將主節(jié)點中 A 的值修改為 Y，那么在這個變更通知到從節(jié)點之前，應用讀取從節(jié)點中的 A 數(shù)據(jù)的值并不為最新的 Y，由此便產(chǎn)生了數(shù)據(jù)不一致的問題。

(2)延時問題。類似 redis 這種組件，數(shù)據(jù)從寫入主節(jié)點到同步至從節(jié)點中的過程需要經(jīng) 歷網(wǎng)絡(luò)→主節(jié)點內(nèi)存→網(wǎng)絡(luò)→從節(jié)點內(nèi)存這幾個階段，整個過程會耗費一定的時間。而在 Kafka 中，主從同步會比 Redis 更加耗時，它需要經(jīng)歷網(wǎng)絡(luò)→主節(jié)點內(nèi)存→主節(jié)點磁盤→網(wǎng)絡(luò)→從節(jié) 點內(nèi)存→從節(jié)點磁盤這幾個階段。對延時敏感的應用而言，主寫從讀的功能并不太適用。

17.Kafka中是怎么體現(xiàn)消息順序性的？

kafka每個partition中的消息在寫入時都是有序的，消費時，每個partition只能被每一個group中的一個消費者消費，保證了消費時也是有序的。整個topic不保證有序。如果為了保證topic整個有序，那么將partition調(diào)整為1.

18.消費者提交消費位移時提交的是當前消費到的最新消息的offset還是offset+1?

offset+1

19.kafka如何實現(xiàn)延遲隊列？

Kafka并沒有使用JDK自帶的Timer或者DelayQueue來實現(xiàn)延遲的功能，而是基于時間輪自定義了一個用于實現(xiàn)延遲功能的定時器（SystemTimer）。JDK的Timer和DelayQueue插入和刪除操作的平均時間復雜度為O(nlog(n))，并不能滿足Kafka的高性能要求，而基于時間輪可以將插入和刪除操作的時間復雜度都降為O(1)。時間輪的應用并非Kafka獨有，其應用場景還有很多，在Netty、Akka、Quartz、Zookeeper等組件中都存在時間輪的蹤影。

底層使用數(shù)組實現(xiàn)，數(shù)組中的每個元素可以存放一個TimerTaskList對象。TimerTaskList是一個環(huán)形雙向鏈表，在其中的鏈表項TimerTaskEntry中封裝了真正的定時任務TimerTask.

Kafka中到底是怎么推進時間的呢？Kafka中的定時器借助了JDK中的DelayQueue來協(xié)助推進時間輪。具體做法是對于每個使用到的TimerTaskList都會加入到DelayQueue中。Kafka中的TimingWheel專門用來執(zhí)行插入和刪除TimerTaskEntry的操作，而DelayQueue專門負責時間推進的任務。再試想一下，DelayQueue中的第一個超時任務列表的expiration為200ms，第二個超時任務為840ms，這里獲取DelayQueue的隊頭只需要O(1)的時間復雜度。如果采用每秒定時推進，那么獲取到第一個超時的任務列表時執(zhí)行的200次推進中有199次屬于“空推進”，而獲取到第二個超時任務時有需要執(zhí)行639次“空推進”，這樣會無故空耗機器的性能資源，這里采用DelayQueue來輔助以少量空間換時間，從而做到了“精準推進”。Kafka中的定時器真可謂是“知人善用”，用TimingWheel做最擅長的任務添加和刪除操作，而用DelayQueue做最擅長的時間推進工作，相輔相成。