什么是消息的可靠性呢，就是Kafka作為消息中間件，可以保證生產(chǎn)者發(fā)送過來的消息，即使在Kafka集群有節(jié)點出現(xiàn)宕機的情況下，也不會丟失
Kafka 是通過消息確認機制 和 副本復(fù)制機制 來保證消息可靠性的文章來源地址http://www.zghlxwxcb.cn/news/detail-650429.html

什么是副本因子？什么是副本復(fù)制機制呢？

• 創(chuàng)建topic時，可以指定副本因子 repilication-factor = 3，默認是3
  • 表示分區(qū)的副本數(shù)，包括Leader分區(qū)副本和follower分區(qū)副本
  • 副本因子不要超過broker的數(shù)量，盡量保證一個分區(qū)的副本均勻地分散在不同的broker上
  • 第一個副本通過輪詢的方式分配broker，從broker列表中隨機位置開始輪詢（生成一個隨機數(shù)，選定第一個broker，然后開始逐個輪詢broker放副本）
  • 副本機制主要是為了實現(xiàn)高可用
• Leader 副本只有一個，負責讀寫，其他節(jié)點都是Follower副本，
• Producer 只把消息發(fā)送到Leader分區(qū)，F(xiàn)ollower副本負責從Leader同步數(shù)據(jù)
• 也就是說在Kafka集群內(nèi)會一直存在大量數(shù)據(jù)復(fù)制過程，這也會造成Kafka一個性能瓶頸

如何判斷副本是同步副本呢？

• ISR 同步副本列表 （包含Leader）
  • 怎么樣算同步呢
  • replica.lag.max.messages 默認4000條，F(xiàn)ollower消息已經(jīng)滯后Leader4000條，即踢出ISR，新版本已經(jīng)取消該規(guī)則
  • replica.lag.max.ms 默認10000ms, 10s內(nèi)Follower 還沒有向Leader發(fā)送fetch請求，即踢出ISR
    • 新版本只通過該規(guī)則識別有效副本
    • 當Follower副本將Leader副本LEO之前的所有消息都同步時，認為該副本已經(jīng)追趕上Leader副本
    • 更新該副本的lastCaughtUpTimeMs 最后拉取數(shù)據(jù)的時間戳
    • ReplicaManager 副本管理器 會啟動一個定時任務(wù)
    • 定時任務(wù)定時監(jiān)測 當前時間 與 lastCaughtUpTimeMs 的差值 是否大于replica.lag.max.ms 值
    • 大于即說明當前副本失效，踢出ISR
  • 每條消息都帶時間戳，生產(chǎn)者不帶的話broker也會給消息生成時間戳，當查找消息時就是根據(jù)偏移了+時間戳

什么情況會導致副本失效呢？

• 卡副本（Stuck Replica） Follower副本進程卡住，一段時間內(nèi)沒有向Leader副本發(fā)起請求，比如Follower副本所在的broker內(nèi)存滿了，頻繁發(fā)起Full GC，我們知道Full GC時會STW（stop the world ），啥也干不了了
• 慢副本（Slow Replica） Follower 副本進程同步過慢，網(wǎng)絡(luò)或者IO開銷過大或機器性能問題，導致Follower在一段時間內(nèi)無法趕上Leader
• 剛啟動副本（BootStrapping Replica） 改變副本因子，比如增加一個副本，新增副本在同步Leader數(shù)據(jù)時，也會一直處于失效狀態(tài)； Follower節(jié)點由于宕機下線了，后又上線，在追趕上Leader副本之前也處于失效狀態(tài)

如何保證消息的可靠性呢？

• 為了保證可靠性，可以設(shè)置確認機制ack= all，
  • Producer將消息發(fā)送給Leader
  • Leader會等到ISR中所有Follower同步數(shù)據(jù)發(fā)送ack
  • Leader 再commit，Leader再向Producer發(fā)送ack
  • 保證生產(chǎn)者發(fā)送的消息實際寫入所有副本

到了這里，關(guān)于Kafka 入門到起飛 - Kafka是怎么保證可靠性的呢的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！