![file file](http://static.javashuo.com/static/loading.gif)
消息路由策略
- productor 選取 partition 分區的策略(broker contorller 將當前 topic 全部的partition leader 返回給 productor )
- 直接指定了partition,則直接寫入到partition
- 沒有指定paritition,可是指定了key,經過key的hash值與 partition 數量取模,該取模的結果就是要選出的partiton索引
- 若 partition 和key 都沒有指定,輪詢算法選一個
消息寫入算法
- 生成者 向 broker 提交鏈接請求,鏈接上的任意broker 都會向其發送 broker controller 的通訊url
- 生成者 指定要消費的topic, broker controller 接受到請求後,從zk中查找指定topic 的全部 partition 的leader 。返回給生成者
- 生產者 接受到 leader 的列表後, 根據消息路由策略選擇要發送的 partition leader。將消息發出
- leader 將消息寫入到 本地log。 並通知isr 中的 follower
- isr 中的followers 從leader 同步信息後,向leader 響應ack
- leader 收到全部的ack後, 增長HW, 標識消費者能夠消費到該位置了。
消息寫入過程存在哪些問題?
- leader 接受到消息後,宕機怎麼辦,leader 可能由於網絡問題,接不到消息?
- partition leader 選舉的過程當中 ISR 列表中沒有從節點怎麼辦?
- leader 沒有收到全部的ack的時候,宕機了。會存在問題?
- 生產者生產消息後,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