kakka 消息寫入工做原理

file

消息路由策略

  • productor 選取 partition 分區的策略(broker contorller 將當前 topic 全部的partition leader 返回給 productor )
  1. 直接指定了partition,則直接寫入到partition
  2. 沒有指定paritition,可是指定了key,經過key的hash值與 partition 數量取模,該取模的結果就是要選出的partiton索引
  3. 若 partition 和key 都沒有指定,輪詢算法選一個

消息寫入算法

  1. 生成者 向 broker 提交鏈接請求,鏈接上的任意broker 都會向其發送 broker controller 的通訊url
  2. 生成者 指定要消費的topic, broker controller 接受到請求後,從zk中查找指定topic 的全部 partition 的leader 。返回給生成者
  3. 生產者 接受到 leader 的列表後, 根據消息路由策略選擇要發送的 partition leader。將消息發出
  4. leader 將消息寫入到 本地log。 並通知isr 中的 follower
  5. isr 中的followers 從leader 同步信息後,向leader 響應ack
  6. leader 收到全部的ack後, 增長HW, 標識消費者能夠消費到該位置了。

消息寫入過程存在哪些問題?

  1. leader 接受到消息後,宕機怎麼辦,leader 可能由於網絡問題,接不到消息?
  2. partition leader 選舉的過程當中 ISR 列表中沒有從節點怎麼辦?
  3. leader 沒有收到全部的ack的時候,宕機了。會存在問題?
  4. 生產者生產消息後,broker 沒有給返回ack,超時後,從新提交消息問題

1.消息發送可靠性機制

  • 經過配置可靠性級別 ack 參數的值進行設置
  • 0 值, 異步發送,生產者 發送消息後,不須要 kafka 反饋成功ack。效果高。可靠性低。有可能存在消息丟失
  • 1 值,同步發送,partition leader 收到消息後, 立刻發送成長ack。存在的問題 是 當leader收到消息後, 尚未向follower 同步, leader 掛了。原來寫入到leader 中的消息丟失了。
  • -1 值,同步發送,當全部partition的副本都同步完消息後, 才能向生產者發送ack。若是超時後, 生產者會自動重發。 不多出現消息丟失。存在重複消息接受狀況。kafka 運行爲消息生成惟一標識。容許用戶自定義去重。

2. partition leader的選舉範圍

  • ISR 列表中沒其餘副本的時候 。能夠經過 參數 unclean.leader.election.enable 取值 設置leader 選舉
  • false 標識有副本活過來 才進行選舉,該策略可靠性有保證。可是可用性低
  • true 標識從任何沒有宕機的follower 中選一個,可能存在大量的消息丟失。可靠性沒有保障

3. HW 截斷機制

leader 收到消息後,ISR 中其它Follower 正在進行同步過程當中,還未同步完畢。leader 宕機。會出現 paritition中的 leader 和follower的數據不一致
。使用截斷。當leader 恢復後,將其從leo回退到 其宕機時候的HW。而後再與新的leader 進行數據同步。算法

(HW截斷機制可能會引起消息的丟失)segmentfault

相關文章
相關標籤/搜索