按照Kafka现有的代码逻辑而言，此功能完全可以实现，不过也会使得代码的复杂度急剧增大。
另外实现此功能需要考虑的因素很多，比如删除掉的分区中的消息该作何处理？
如果随着分区一起消失则消息的可靠性得不到保障；
如果需要保留则又需要考虑如何保留，直接存储到现有分区的尾部，消息的时间戳就不会递增，如此对于Spark、Flink这类需要消息时间戳（事件时间）的组件将会受到影响；
如果分散插入到现有的分区中，那么在消息量很大的时候，内部的数据复制会占用很大的资源，而且在复制期间，此主题的可用性又如何得到保障？
同时，顺序性问题、事务性问题、以及分区和副本的状态机切换问题都是不得不面对的。
由此可知这个功能的收益点是很低的，如果真的需要实现此类的功能，完全可以重新创建一个分区数较小的主题，然后将现有主题中的消息按照既定的逻辑复制过去即可。
kafka的ack机制有3种：0，1，-1；这3种会围绕持久性和延时性来比较
0：最差的持久性，最低的延时性
这一操作提供了一个最低的延迟，partition的leader副本接收到消息还没有写入磁盘就已经返回ack，当leader故障时有可能丢失数据；
例如leader已经死亡，producer不知情，还会继续发送消息broker接收不到数据就会数据丢失