勿忘我

一个topic多个partion，一个partion对应一个文件目录，一个partion对应多个segment，一个segment中有一个XXX.log文件和一个XXX.index文件，你说的50个是不是文件个数？或者你把你的50个分区的文件名列出来看看呢。

一个topic多个partion，一个partion对应一个文件目录，一个partion对应多个segment，一个segment中有一个XXX.log文件和一个XXX.index文件，你说的50个是不是文件个数？或者你把你的50个分区的文件名列出来看看呢。

一个topic多个partion，一个partion对应一个文件目录，一个partion对应多个segment，一个segment中有一个XXX.log文件和一个XXX.index文件，你说的50个是不是文件个数？或者你把你的50个分区的文件名列出来看看呢。

broker就是kafka应用程序本身了，parition可以理解为队列，1个kafka服务可以有多个partition，kakfa的副本容错都是基于parition的，客户端也是根据分区数来建立长连接来消费这些parition。数量的比例好坏都是基于服务器的物理性能来决定的。

比如：1台kafka服务器，有5个parition，这5个parition的有的数据量大，有的数据量小，有的并发高，有的并发少。
但是，它们共享是物理层的带宽能力，cpu能力，内存能力。如果你总体就10M带宽，你怎么分，都是这么多，5个partition，10个parition，都是10M。所以还是要看物理能力，业务压力等。

等你有具体业务场景，到问答专区详细提问，我在帮你具体分析。

你要控制consumer如何提交offset了，如果你业务很多问题，消费者写的不好，你还要面临重复消费或漏消息的问题。

你的问题一开始就说明了在特定的分区上，我理解的是你已经做了分区指定规则，而不是因为有了新的就发到新的。
有了新的分区，也必须是通过自己的规则，将特定的一类消息放到该分区上，才行。

kafka的乱序是consumer造成的，parition先进先出顺序保证，但是消费者的能力不一，有的处理的快，有的处理的慢，必定会乱，所以kafka推荐如果需要强一致，就只能有1个分区。而你通过规则设置不同的key，消费分到“特定的分区”，和kafka的1个分区效果是一样的。

1.磁盘删除文件后，释放文件资源后，broker进程不能识别磁盘的空闲资源吗，或者是要等一段时间后才会同步到broker进程中，如果重启broker就会立即触发更新，所以重启后就可以了
2.分区数据还是不能成功写入 有具体的日志报错提示嘛？
3.可以手动将分区目录下的比较老的已经消费了日志文件删除了，不要等异步线程自己去删除，然后是不是可以了
4.Kafka有2个参数控制删除已经消费了的数据，一个是根据时间，一个是根据空间，参数是不是需要调整一下
5.操作之前能先暂停生产数据流入

我只能思考到这，我认为这是典型一个消息积压后，集群不可用的问题

一个topic多个partion，一个partion对应一个文件目录，一个partion对应多个segment，一个segment中有一个XXX.log文件和一个XXX.index文件，你说的50个是不是文件个数？或者你把你的50个分区的文件名列出来看看呢。