需求：
要对于几个业务topic进行基于broker级别的物理资源隔离
步骤
1：Ambari2.7.x基于HDP3.x进行kafka集群扩容
用于隔离的broker是若干台新机子
在ambari界面–主机–add—kafka broker
进行kafka的broker扩容
2：登陆zk查看扩容机对应的broker id
sh zkcli.sh
ls /broker/ids
get每一个broker id的值，查询新增的brokers 主机名对应的broker id，一般都是基于之前的broker id进行追加，比如之前一共有10台broker，由1001到1010，然后扩容了4台，则新的broker id为1011到1014，与hostname一一对应（前提是你的hostname都是按顺序的噢）
3：创建新topic时进行物理隔离
在创建topic的时候加上replica-assignment参数，后面的值用逗号分隔每个partition，每个partition中冒号分隔副本所在的broker。例如通过下面的命令创建两个topic。
./kafka-topics.sh --zookeeper hostA:2181 --create --topic user1 --replica-assignment 1008:1001,1007:1002
./kafka-topics.sh --zookeeper hostA:2181 --create --topic user1 --replica-assignment 1010:1003,1009:1004
注意：这里创建topic时不能添加–partitions与–replication-factor参数，因为那是自动分配，这里是通过–replica-assignment进行手动分配（隔离）
查看创建之后的user1 topic 的partition分布，partition0的leader是1008，副本在1008和1001，partition1也是和预期的一致.
user2一样
describe如下
./kafka-topics.sh --describe --zookeeper hostA:2181 --topic user1,user2
Topic:user1 PartitionCount:2 ReplicationFactor:2 Configs:
Topic: user1 Partition: 0 Leader: 1008 Replicas: 1008,1001 Isr: 1008,1001
Topic: user1 Partition: 1 Leader: 1007 Replicas: 1007,1002 Isr: 1007,1002
Topic:user2 PartitionCount:2 ReplicationFactor:2 Configs:
Topic: user2 Partition: 0 Leader: 1010 Replicas: 1010,1003 Isr: 1010,1003
Topic: user2 Partition: 1 Leader: 1009 Replicas: 1009,1004 Isr: 1009,1004
4：分析
3中的结果已经表明了 用replica-assignment新创建的2个topic已经分布在不同的broker中了，副本也在完全不同的机子中，user1主题的所有分区的副本一直在1008，1001，1007，1002中，user2主题的所有分区的副本一直在1010，1003，1009，1009中。user1,user2两个主题互不影响。实现了主题在broker级别的物理隔离
其实究其topic创建方式，无非这个参数就是把原本基于固定分区副本数随机分配broker转变成固定分区副本id名称。
id名称固定了，那么分区数，副本数都不需要指定了。
所以省略了–partitions，–replication-factor参数
5：疑问
难道在后续使用的过程中，user1与user2的副本永远不会重叠而造成隔离污染吗？
6：思考
想了下kafka的重平衡机制
有三个参数如下
auto.leader.rebalance.enable=true ## 是否leader自动重平衡
leader.imbalance.check.interval.seconds=300s ## 不均衡扫描间隔时间
leader.imbalance.per.broker.percentage=10 ## 不均衡比率阈值（不均衡比率=leader不等于preferred replicas的分区数/总分区数）
参数不好理解拿下图举个例子
如果满足上图，在
auto.leader.rebalance.enable=true
leader.imbalance.check.interval.seconds=300s
的条件下，进行第三个参数leader.imbalance.per.broker.percentage的判定
iteblog主题的6个分区中只有一个分区的leader不等于replica中的第一个副本id（这里第一个副本就是上文中所说的preferred replica）
比率为1/7，小于10%，所以不会触发leader的重平衡机制
但是如果这个比例大于10%了呢，就会触发重平衡机制，会在所有broker中进行重平衡算法，包括之前新添加的broker（只用于某些topic的物理资源隔离）。
这样子就会导致该topic的分区们将所有的broker宠幸了个遍。破坏了物理隔离
7：优化方式
基于现有业务量，合理将leader.imbalance.per.broker.percentage参数进行增大，15%，20%，像这样，但是也不要太大
8：修正·回滚
发了博客后，我参考官方文档的参数定义，发现6中的三个参数，如果判定生效，他会进行leader的rebalance，但是并不会将隔离前的broker也拉进来一起平衡。而是会在当前topic中将leader不为preferred replica的分区leader改为preferred replica（优先副本），就像刚才那张图
图中1号分区的leader为3，优先副本（preferred replica）却为7。
假设那个平衡比率大于10%了，那么auto.leader.rebalance.enable=true是对leader的负载均衡，不会将扩容前的机子牵扯进来。
leader的rebalance是将leader改为preferred replica。我之前将leader的重平衡跟kafka-reassign-partition脚本搞混了。
kafka-reassign-partition脚本才会对当前topic的所有分区重新分配（如果你自己的执行计划特立独行只修改指定分区当我没说），而auto.leader.rebalance.enable=true只会对某些分区进行操作
上图中编号为3的broker作为分区1、6的leader，压力大，当不均衡比率高于阈值（leader.imbalance.per.broker.percentage）则将分区1的leader更换为7（当然图中的比率是1/7，这里是假设比率高于阈值）。这样子编号3broker就很舒服了
那么得出结论
kafka的–replica-assignment参数所生成的topic的分区副本永远不会改变，除非手动指定执行计划运行kafka-reassign-partition脚本来修改分区的副本id，所以无需修改leader.imbalance.per.broker.percentage阈值
