Kafka 如何做到高吞吐、低延遲呢？

這里提下 Kafka 寫數(shù)據(jù)的大致方式：先寫操作系統(tǒng)的頁(yè)緩存(Page Cache),然后由操作系統(tǒng)自行決定何時(shí)刷到磁盤。

因此 Kafka 達(dá)到高吞吐、低延遲的原因主要有以下 4 點(diǎn)：

• 頁(yè)緩存是在內(nèi)存中分配的，所以消息寫入的速度很快。
• Kafka 不必和底層的文件系統(tǒng)進(jìn)行交互，所有繁瑣的 I/O 操作都由操作系統(tǒng)來(lái)處理。
• Kafka 采用追加寫的方式，避免了磁盤隨機(jī)寫操作。
• 使用以 sendfile 為代表的零拷貝技術(shù)提高了讀取數(shù)據(jù)的效率。

PS: 使用頁(yè)緩存而非堆內(nèi)存還有一個(gè)好處，就是當(dāng) Kafka broker 的進(jìn)程崩潰時(shí)，堆內(nèi)存的數(shù)據(jù)會(huì)丟失，但是頁(yè)緩存的數(shù)據(jù)依然存在，重啟 Kafka broker 后可以繼續(xù)提供服務(wù)。

2. Kafka 的 producer 工作流程？

封裝為 ProducerRecord 實(shí)例

序列化

由 partitioner 確定具體分區(qū)

發(fā)送到內(nèi)存緩沖區(qū)

由 producer 的一個(gè)專屬 I/O 線程去取消息，并將其封裝到一個(gè)批次 ，發(fā)送給對(duì)應(yīng)分區(qū)的 kafka broker

leader 將消息寫入本地 log

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

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

3. Kafka 的 consumer 工作流程？

連接 ZK 集群，拿到對(duì)應(yīng) topic 的 partition 信息和 partition 的 leader 的相關(guān)信息

連接到對(duì)應(yīng) leader 對(duì)應(yīng)的 broker

consumer 將自己保存的 offset 發(fā)送給 leader

leader 根據(jù) offset 等信息定位到 segment(索引文件和日志文件)

根據(jù)索引文件中的內(nèi)容，定位到日志文件中該偏移量對(duì)應(yīng)的開始位置讀取相應(yīng)長(zhǎng)度的數(shù)據(jù)并返回給 consumer

4. 重要參數(shù)有哪些？

acks

• acks = 0 : 不接收發(fā)送結(jié)果
• acks = all 或者 -1: 表示發(fā)送消息時(shí)，不僅要寫入本地日志，還要等待所有副本寫入成功。
• acks = 1: 寫入本地日志即可，是上述二者的折衷方案，也是默認(rèn)值。

retries

• 默認(rèn)為 0，即不重試，立即失敗。一個(gè)大于 0 的值，表示重試次數(shù)。

buffer.memory

• 指定 producer 端用于緩存消息的緩沖區(qū)的大小，默認(rèn) 32M；適當(dāng)提升該參數(shù)值，可以增加一定的吞吐量。

batch.size

• producer 會(huì)將發(fā)送分區(qū)的多條數(shù)據(jù)封裝在一個(gè) batch 中進(jìn)行發(fā)送，這里的參數(shù)指的就是 batch 的大小。該參數(shù)值過小的話，會(huì)降低吞吐量，過大的話，會(huì)帶來(lái)較大的內(nèi)存壓力。默認(rèn)為 16K，建議合理增加該值。

5. 丟失數(shù)據(jù)的場(chǎng)景？

• consumer 端：不是嚴(yán)格意義的丟失，其實(shí)只是漏消費(fèi)了。
  設(shè)置了 auto.commit.enable=true ，當(dāng) consumer fetch 了一些數(shù)據(jù)但還沒有完全處理掉的時(shí)候，剛好到 commit interval 觸發(fā)了提交 offset 操作，接著 consumer 掛掉。這時(shí)已經(jīng)fetch的數(shù)據(jù)還沒有處理完成但已經(jīng)被commit掉，因此沒有機(jī)會(huì)再次被處理，數(shù)據(jù)丟失。
• producer 端：
  I/O 線程發(fā)送消息之前，producer 崩潰， 則 producer 的內(nèi)存緩沖區(qū)的數(shù)據(jù)將丟失。

6. producer 端丟失數(shù)據(jù)如何解決？

• 同步發(fā)送，性能差，不推薦。
• 仍然異步發(fā)送，通過“無(wú)消息丟失配置”(來(lái)自胡夕的《Apache Kafka 實(shí)戰(zhàn)》)極大降低丟失的可能性：

block.on.buffer.full = true 盡管該參數(shù)在0.9.0.0已經(jīng)被標(biāo)記為“deprecated”，但鑒于它的含義非常直觀，所以這里還是顯式設(shè)置它為true，使得producer將一直等待緩沖區(qū)直至其變?yōu)榭捎谩７駝t如果producer生產(chǎn)速度過快耗盡了緩沖區(qū)，producer將拋出異常

acks=all 很好理解，所有follower都響應(yīng)了才認(rèn)為消息提交成功，即"committed"

retries = MAX 無(wú)限重試，直到你意識(shí)到出現(xiàn)了問題:)

max.in.flight.requests.per.connection = 1 限制客戶端在單個(gè)連接上能夠發(fā)送的未響應(yīng)請(qǐng)求的個(gè)數(shù)。設(shè)置此值是1表示kafka broker在響應(yīng)請(qǐng)求之前client不能再向同一個(gè)broker發(fā)送請(qǐng)求。注意：設(shè)置此參數(shù)是為了避免消息亂序

使用KafkaProducer.send(record, callback)而不是send(record)方法 自定義回調(diào)邏輯處理消息發(fā)送失敗

callback邏輯中最好顯式關(guān)閉producer：close(0) 注意：設(shè)置此參數(shù)是為了避免消息亂序

unclean.leader.election.enable=false 關(guān)閉unclean leader選舉，即不允許非ISR中的副本被選舉為leader，以避免數(shù)據(jù)丟失

replication.factor >= 3 這個(gè)完全是個(gè)人建議了，參考了Hadoop及業(yè)界通用的三備份原則

min.insync.replicas > 1 消息至少要被寫入到這么多副本才算成功，也是提升數(shù)據(jù)持久性的一個(gè)參數(shù)。與acks配合使用

保證replication.factor > min.insync.replicas 如果兩者相等，當(dāng)一個(gè)副本掛掉了分區(qū)也就沒法正常工作了。通常設(shè)置replication.factor = min.insync.replicas + 1即可

7. consumer 端丟失數(shù)據(jù)如何解決？

enable.auto.commit=false 關(guān)閉自動(dòng)提交位移，在消息被完整處理之后再手動(dòng)提交位移

8. 重復(fù)數(shù)據(jù)的場(chǎng)景？

網(wǎng)絡(luò)抖動(dòng)導(dǎo)致 producer 誤以為發(fā)送錯(cuò)誤，導(dǎo)致重試，從而產(chǎn)生重復(fù)數(shù)據(jù)，可以通過冪等性配置避免。

9. 分區(qū)策略(即生產(chǎn)消息時(shí)如何選擇哪個(gè)具體的分區(qū))？

• 指定了 key ，相同的 key 會(huì)被發(fā)送到相同的分區(qū)；
• 沒有指定 key，通過輪詢保證各個(gè)分區(qū)上的均勻分配。

10. 亂序的場(chǎng)景？

消息的重試發(fā)送。

11. 亂序如何解決？

參數(shù)配置 max.in.flight.requests.per.connection = 1 ，但同時(shí)會(huì)限制 producer 未響應(yīng)請(qǐng)求的數(shù)量，即造成在 broker 響應(yīng)之前，producer 無(wú)法再向該 broker 發(fā)送數(shù)據(jù)。

12. 如何選擇 Partiton 的數(shù)量？

• 在創(chuàng)建 Topic 的時(shí)候可以指定 Partiton 數(shù)量，也可以在創(chuàng)建完后手動(dòng)修改。但 Partiton 數(shù)量只能增加不能減少。中途增加 Partiton 會(huì)導(dǎo)致各個(gè) Partiton 之間數(shù)據(jù)量的不平等。
• Partition 的數(shù)量直接決定了該 Topic 的并發(fā)處理能力。但也并不是越多越好。Partition 的數(shù)量對(duì)消息延遲性會(huì)產(chǎn)生影響。
• 一般建議選擇 Broker Num * Consumer Num ，這樣平均每個(gè) Consumer 會(huì)同時(shí)讀取 Broker 數(shù)目個(gè) Partition ， 這些 Partition 壓力可以平攤到每臺(tái) Broker 上。

13. 可重試的異常情況有哪些？

• 分區(qū)的 leader 副本不可用，一般發(fā)生再 leader 換屆選舉時(shí)。
• controller 當(dāng)前不可用，一般是 controller 在經(jīng)歷新一輪的選舉。
• 網(wǎng)絡(luò)瞬時(shí)故障。

14. controller 的職責(zé)有哪些？

在 kafka 集群中，某個(gè) broker 會(huì)被選舉承擔(dān)特殊的角色，即控制器(controller)，用于管理和協(xié)調(diào) kafka 集群，具體職責(zé)如下：

• 管理副本和分區(qū)的狀態(tài)
• 更新集群元數(shù)據(jù)信息
• 創(chuàng)建、刪除 topic
• 分區(qū)重分配
• leader 副本選舉
• topic 分區(qū)擴(kuò)展
• broker 加入、退出集群
• 受控關(guān)閉
• controller leader 選舉

15. leader 掛了會(huì)怎樣？(leader failover)

當(dāng) leader 掛了之后，controller 默認(rèn)會(huì)從 ISR 中選擇一個(gè) replica 作為 leader 繼續(xù)工作，條件是新 leader 必須有掛掉 leader 的所有數(shù)據(jù)。

如果為了系統(tǒng)的可用性，而容忍降低數(shù)據(jù)的一致性的話，可以將 unclean.leader.election.enable = true ，開啟 kafka 的"臟 leader 選舉"。當(dāng) ISR 中沒有 replica，則會(huì)從 OSR 中選擇一個(gè) replica 作為 leader 繼續(xù)響應(yīng)請(qǐng)求，如此操作提高了 Kafka 的分區(qū)容忍度，但是數(shù)據(jù)一致性降低了。

16. broker 掛了會(huì)怎樣？(broker failover)

broker上面有很多 partition 和多個(gè) leader 。因此至少需要處理如下內(nèi)容：

• 更新該 broker 上所有 follower 的狀態(tài)
• 從新給 leader 在該 broker 上的 partition 選舉 leader
• 選舉完成后，要更新 partition 的狀態(tài)，比如誰(shuí)是 leader 等

kafka 集群?jiǎn)?dòng)后，所有的 broker 都會(huì)被 controller 監(jiān)控，一旦有 broker 宕機(jī)，ZK 的監(jiān)聽機(jī)制會(huì)通知到 controller， controller 拿到掛掉 broker 中所有的 partition，以及它上面的存在的 leader，然后從 partition的 ISR 中選擇一個(gè) follower 作為 leader，更改 partition 的 follower 和 leader 狀態(tài)。

17. controller 掛了會(huì)怎樣？(controller failover)

• 由于每個(gè) broker 都會(huì)在 zookeeper 的 "/controller" 節(jié)點(diǎn)注冊(cè) watcher，當(dāng) controller 宕機(jī)時(shí) zookeeper 中的臨時(shí)節(jié)點(diǎn)消失
• 所有存活的 broker 收到 fire 的通知，每個(gè) broker 都嘗試創(chuàng)建新的 controller path，只有一個(gè)競(jìng)選成功并當(dāng)選為 controller。

18. Zookeeper 為 Kafka 做了什么？

管理 broker 與 consumer 的動(dòng)態(tài)加入與離開。(Producer 不需要管理，隨便一臺(tái)計(jì)算機(jī)都可以作為Producer 向 Kakfa Broker 發(fā)消息)

觸發(fā)負(fù)載均衡，當(dāng) broker 或 consumer 加入或離開時(shí)會(huì)觸發(fā)負(fù)載均衡算法，使得一個(gè) consumer group 內(nèi)的多個(gè) consumer 的消費(fèi)負(fù)載平衡。(因?yàn)橐粋€(gè) comsumer 消費(fèi)一個(gè)或多個(gè)partition，一個(gè) partition 只能被一個(gè) consumer 消費(fèi))

維護(hù)消費(fèi)關(guān)系及每個(gè) partition 的消費(fèi)信息。

19. Page Cache 帶來(lái)的好處。

Linux 總會(huì)把系統(tǒng)中還沒被應(yīng)用使用的內(nèi)存挪來(lái)給 Page Cache，在命令行輸入free，或者 cat /proc/meminfo，“Cached”的部分就是 Page Cache。

Page Cache 中每個(gè)文件是一棵 Radix 樹(又稱 PAT 位樹, 一種多叉搜索樹)，節(jié)點(diǎn)由 4k 大小的 Page 組成，可以通過文件的偏移量(如 0x1110001)快速定位到某個(gè)Page。

當(dāng)寫操作發(fā)生時(shí)，它只是將數(shù)據(jù)寫入 Page Cache 中，并將該頁(yè)置上 dirty 標(biāo)志。

當(dāng)讀操作發(fā)生時(shí)，它會(huì)首先在 Page Cache 中查找，如果有就直接返回，沒有的話就會(huì)從磁盤讀取文件寫入 Page Cache 再讀取。

可見，只要生產(chǎn)者與消費(fèi)者的速度相差不大，消費(fèi)者會(huì)直接讀取之前生產(chǎn)者寫入Page Cache的數(shù)據(jù)，大家在內(nèi)存里完成接力，根本沒有磁盤訪問。

而比起在內(nèi)存中維護(hù)一份消息數(shù)據(jù)的傳統(tǒng)做法，這既不會(huì)重復(fù)浪費(fèi)一倍的內(nèi)存，Page Cache 又不需要 GC (可以放心使用60G內(nèi)存了)，而且即使 Kafka 重啟了，Page Cache 還依然在。

出處：http://dwz.date/bvVf

總結(jié)

以上是生活随笔為你收集整理的kafka中controller的作用_Kafka 常见问题汇总的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。