今天回答几个问题。这个是一个星球同学提的，我们长话短说。适用于实际工作以及面试。
关于GC
这里特指Full GC。
首先Flink中的TaskManager的GC监控是一个非常重要的监控，GC频繁会导致你的任务处理速度降低，发生TM lost，任务fail over，更严重的会直接OOM，任务挂掉。
一般我们通过Promethus这样的框架去监控Flink任务，最容易监控的就是Full GC的次数。首先必须纠正一个误区，Full GC的次数不是越低越好。因为GC次数低很有可能是因为你的内存资源利用率不高导致的，Full GC有两个评价指标：次数和时长。这两个指标都保证在一个合理的范围内即可。
如果你需要指导更加详细的GC Detail，那么你需要跳转到TaskManager对应的机器上通过类似Arthas这样的工具查看当前机器的线程、火焰图等信息，协助你精确的定位问题。
关于Task的数据分布
Flink任务会精确的显示TaskManger/Task中的数据消费信息，可以直观地看到input和ouput情况，这是我们判断数据倾斜的最直观的方式。
查询数据倾斜的方式很简单，从TM角度去看是否存在某一个/几个TM的数据条数明显高于其他TM，即可判断当前的TM发生了数据倾斜。
但是数据倾斜不是说一定会引起问题。轻微的数据倾斜也不是不能接受，只要不出现反压即可。
这里多扯一句，Flink的资源分配是按照TM维度去做分配，如果发生了数据倾斜，那么需要全局增加资源，那么没有发生数据倾斜的那些TM的资源利用率就会很低，然后整体任务的资源利用率就会被拉低。
所以，你说增加资源能不能解决数据倾斜问题呢？答案是能有效缓解，但是代价就是整个任务的资源利用率变得很低。
关于数据倾斜的处理方式，并行度问题
我们这里不讲数据倾斜的处理方式，这个讲过太多次了。
这里有个更核心的问题是：增加并行度能否解决数据倾斜问题？
首先这里有一个误区是，数据倾斜跟并行度关系并不大。数据倾斜产生的原因是因为：数据分配出了问题。
所以，假如说增加并行度能解决数据分配问题，那么就能解决数据倾斜问题，反之亦然。
所以我们解决数据倾斜问题的出发点应该是：解决数据分配问题。
你看这跟解决贫富差距问题是一样的，只要你能改变财富的分配方式那么就能解决贫富差距。
回到问题本身，例如你的数据倾斜是因为Distributing参数配置错误，导致的，那么你可以修改StreamPartitioner即可。例如，你可以把这个参数设置为rebalance，那么大多数情况下是能有效缓解数据倾斜问题。
另外还有一个前缀后缀、采样热点数据隔离等方式，跟Hive/Spark处理数据倾斜问题大同小异，不再赘述。
关于Kafka partition数量和消费并行度的关系
首先，我强烈建议你把消费端的并行度设置为Kafka partition的数量。
其次，我强烈建议你把StreamPartitioner设置为rebalance，这样起码流入到Flink任务的数据是均匀的。可以有效避免因为读取Kafka中数据导致的数据不均问题出现。
Redistributing参数
如果你没有特别的要求，直接把这个参数设置为rebalance。可以有效避免Flink任务进行数据数据分发时导致的数据不均。
