Kafka如何修改分區Leader
前幾天有個群友問我: kafka如何修改優先副本? 他們有個需求是, 想指定某個分區中的其中一個副本為Leader
在這里插入圖片描述
需求分析
對于這么一個問題,在我們生產環境還是挺常見的,經常有需要修改某個Topic中某分區的Leader
比如 topic1-0這個分區有3個副本[0,1,2], 按照「優先副本」的規則
那么 0 號副本肯定就是Leader了 我們都知道分區中的只有Leader副本才會提供讀寫副本
其他副本作為備份 假如在某些情況下,「0」 號副本性能資源不夠,或者網絡不太好,或者IO壓力比較大
那么肯定對Topic的整體讀寫性能有很大影響, 這個時候切換一臺壓力較小副本作為Leader就顯得很重要;
優先副本: 分區中的AR(所有副本)信息, 優先選擇排在第一位的副本作為Leader
Leader機制: 分區中只有一個Leader來承擔讀寫,其他副本只是作為備份
那么如何實現這樣一個需求呢?
解決方案
知道了原理之后,我們就能想到對應的解決方案了 只要將 分區的 AR 中的第一個位置,替換成你指定副本就行了;AR = { 0,1,2 } ==> AR = {2,1,0}
一般能夠達到這個目的有兩種方案，下面我們來分析一下
方案一: 分區副本重分配
之前關于分區副本重分配 我已經寫過很多文章了,如果想詳細了解 分區副本重分配、數據遷移、副本擴縮容 可以看看鏈接的文章, 這里我就簡單說一下;
一般分區副本重分配主要有三個流程
- 生成推薦的遷移Json文件
- 執行遷移Json文件
- 驗證遷移流程是否完成
這里我們主要看第2步驟, 來看看遷移文件一般是什么樣子的
- {
- "version": 1,
- "partitions": [{
- "topic": "topic1",
- "partition": 0,
- "replicas": [0,1,2]
- }]
- }
這個遷移Json意思是, 把topic1的「0」號分區的副本分配成[0,1,2] ,也就是說 topic1-0號分區最終有3個副本分別在 {brokerId-0,brokerId-1,brokerId-2} ;
如果你有看過我之前寫的 分區副本重分配原理源碼分析 ，那么肯定就知道
不管你之前的分配方式是什么樣子的, 最終副本分配都是 [0,1,2] , 之前副本多的,會被刪掉,少的會被新增;
那么我們想要實現 我們的需求 是不是把這個Json文件 中的 "replicas": [0,1,2] 改一下就行了
比如改成 "replicas": [2,1,0] 改完Json后執行,執行execute, 正式開始重分配流程! 遷移完成之后, 就會發現,Leader已經變成上面的第一個位置的副本「2」 了
優缺點
優點: 實現了需求, 并且主動切換了Leader
缺點: 操作比較復雜容易出錯,需要先獲取原先的分區分配數據,然后手動修改Json文件,這里比較容易出錯,影響會比較大,當然這些都可以通過校驗接口來做好限制, 最重要的一點是 副本重分配當前只能有一個任務 ! 假如你當前有一個「副本重分配」的任務在,那么這里就不能夠執行了, 「副本重分配」是一個比較「重」 了的操作,出錯對集群的影響比較大
方案二: 手動修改AR順序
首先,我們知道分區副本的分配數據是保存在zookeeper中的節點brokers/topics/{topicName} 中; 我們看個Topic1的節點數據例子;
- {
- "version": 2,
- "partitions": {
- "2": [3, 2, 1],
- "1": [2, 1, 3],
- "4": [2, 3, 1],
- "0": [1, 3, 2],
- "3": [1, 2, 3]
- },
- "adding_replicas": {},
- "removing_replicas": {}
- }
數據解釋:version:版本信息, 現在有 「1」、「2」 兩個版本
removing_replicas:需要刪除的副本數據, 在進行分區副本重分配過程中, 多余的副本會在數據遷移快完成的時候被刪除掉，刪除成功這里的數據會被清除
adding_replicas:需要新增的副本數據，在進行分區副本重分配過程中, 新增加的副本將會被新增,新增完成這里的數據會清除;
partitions:Topic的所有分區副本分配方式; 上面表示總共有5個分區,以及對應的副本位置;
知道了這些之后,想要修改優先副本,是不是可以通過直接修改zookeeper中的節點數據就行了; 比如 我們把 「1」號分區的副本位置改成 [2,1,3]
改成這樣之后, 還需要 執行 重新進行優先副本選舉操作 ,例如通過kafka的命令執行
- sh bin/kafka-leader-election.sh --bootstrap-server xxxx:9090 --topic Topic1--election-type PREFERRED --partition 1
--election-type : PREFERRED 這個表示的以優先副本的方式進行重新選舉
那么做完這兩步之后, 我們的修改優先副本的目的就達成了.........嗎 ?
實則并沒有, 因為這里僅僅只是修改了 zookeeper節點的數據
而bin/kafka-leader-election.sh 重選舉的操作是Controller來進行的; 如果你對Controller的作用和源碼足夠了解
肯定知道Controller里面保存了每個Topic的分區副本信息, 是保存在JVM內存中的, 然后我們手動修改Zookeeper中的節點,并沒有觸發 Controller更新自身的內存
也就是說 就算我們執行了kafka-leader-election.sh, 它也不會有任何變化,因為優先副本沒有被感知到修改了;
解決這個問題也很簡單,讓Controller感知到數據的變更就行了 最簡單的方法, 讓Controller發生重新選舉, 數據重新加載!
總結
手動修改zookeeper中的「AR」順序
Controller 重新選舉
執行 分區副本重選舉操作(優先副本策略)
簡單代碼
當然上面功能,肯定是要集成到LogiKM中的咯; 簡單代碼如下
- // 這里轉換成HashMap類型,切勿自定義類型,以防kafka節點數據后續新增數據節點，導致數據丟失
- HashMap partitionMap = zkConfig.get(ZkPathUtil.getBrokerTopicRoot(topicName), HashMap.class);
- JSONObject partitionJson = (JSONObject)partitionMap.get("partitions");
- JSONArray partitions = (JSONArray)partitionJson.get(partition);
- //部分代碼省略
- //調換序列 優先副本
- Integer first = partitions.getInteger(0);
- partitions.set(0,targetBroker);
- partitions.set(index,first);
- zkUtils = ZookeeperUtils.getKafkaZkUtils(clusterDO.getZookeeper());
- String json = JSON.toJSONString(partitionMap);
- zkUtils.updatePersistentPath(ZkPathUtil.getBrokerTopicRoot(topicName), json,null);
- //寫入成功之后觸發一下 異步去優先副本選舉
- new Thread(()->{
- try {
- // 1. 先讓Controller重新選舉 (不然上面修改的還沒有生效) （TODO.. 待優化 -> 頻繁的Controller重選舉對集群性能會有影響）
- zkConfig.deletePath(ZkPathUtil.CONTROLLER_ROOT_NODE);
- // 等待 Controller 選舉一下
- Thread.sleep(1000);
- //2. 然后再發起副本重新選舉
- preferredReplicalElectCommand.preferredReplicaElection(clusterId,topicName,partition,"");
- } catch (ConfigException | InterruptedException e) {
- LOGGER.error("重新選舉異常.e:{}",e);
- e.printStackTrace();
- }
- }).start();
優缺點
優點: 實現了目標需求, 簡單, 操作方便
缺點: 頻繁的Controller重選舉對生產環境來說會有一些影響;
優化與改進
第二種方案中,需要Controller 重選舉, 頻繁的選舉肯定是對生產環境有影響的;Controller承擔了非常多的責任,比如分區副本重分配、刪除topic、Leader選舉 等等還有很多都是它在干!
那么如何不進行Controller的重選舉,也能達到我們的需求呢?
我們的需求是,當我們 修改了zookeeper中的節點數據的時候，能夠迅速的讓Controller感知到,并更新自己的內存數據就行了;
對于這個問題,我會在下一期文章中介紹
問題
看完這篇文章,提幾個相關的問題給大家思考一下;
如果我在修改zk中的「AR」信息時候不僅僅是調換順序,而是有新增或者刪除副本會發生什么情況呢?
如果手動修改brokers/topics/{topicName}/partitions/{分區號}/state 節點里面的leader信息,能不能直接更新Leader?
副本選舉的整個流程是什么樣子的?
大家可以思考一下, 問題答案我會在后面的文章中一一講解!
