最近发现了一个问题，上周进行broker后端裁撤，比如id为14的ip为1.1.1.1修改成2.2.2.2，裁撤流程基本正常，2.2.2.2的所有配置都和1.1.1.1一样（1.1.1.1已经关闭），但发现了以下几个事情：
裁撤后的机器（2.2.2.2）只有部分topic的partition进行的leader重均衡（比如以前50个leader分区，只有10个自动均衡回去了）
最重要的一点就是发现consumer好像无法自动感知到后端brokerip的变更，导致partition无法正常消费，引起消费延迟，重启consumer之后才能恢复
所以还能老师帮忙分析一下这个是一个什么原理和有没有更好的解决方式，以前认为broker变更是无损的，但是可能还不是想象的那么简单方便，这个场景对于我们业务来说其实相对很是很多的
kafka版本：2.1.1
id相同，kafka集群就会认为是相同的节点。只换ip，并且kafka配置指定的存储也是同样copy过去的话，那就没有问题。
注意，节点恢复之后，看看下节点是否已经进入到isr中了。
平衡可以关注一下：https://www.orchome.com/33
好的老师 我大概明白您说的一部分 换节点正常在isr列表中 目测感觉写入没有受什么影响，但是消费者没有感知到，想这种变更ip的情况你觉得后续如何操作更合适呢（这个场景我们主要是避免不了的），还想听听您的看法和经验，而且我发现了一个事情，就是平衡我这边应该是自动开启的，比如说是10分钟一次，但是我发现当时只有很少很少一部分partition平衡了，后来是我手动执行了一次均衡，才把其它partition均衡回这个节点里面，也是很奇怪的一点，但是还是不清楚原因
我们迁移通常是热迁，新加一个kafka节点到集群中，通过分区迁移工具，把要下架的kafka数据换到新的上面去。
因为数据是持续流入的，我们通常是这么做的。
好的 老师 我理解您的意思了 看来我们这种前期方法在实际场景下还是会有问题 感谢感谢
你的答案