主题作为消息的归类，可以再细分为一个或多个分区，分区可以看作对消息的二级归类。分区的划分不仅为Kafka提供了可伸缩性、水平扩展的功能，还通过多副本机制为Kafka提供数据冗余以提高数据可靠性。
从Kafka的底层来说，主题和分区都是逻辑上的概念，分区可以有一到多个副本，每个副本对应一到多个日志文件，每个日志文件对应一到多个日志分段（LogSegment），每个日志文件可以细分为索引文件、日志存储文件和快照文件等。
1、主题的管理
1.1、创建主题
如果broker端配置参数auto.create.topics.enable配置为true（默认值为true），那么当生产者向一个尚未创建的主题发送消息时，会自动创建一个分区数为num.partitions（默认值为1）、副本因子为default.replication.factor（默认值为1）的主题。很多时候，这种自动创建主题的行为都是非预期的。除非有特殊应用需求，否则不建议将auto.create.topics.enable设置为true。
更加推荐的是通过kafka-topics.sh脚本来创建主题。
bin/kafka-topics.sh --zookeeper localhost:2181/kafka --create --topic topic-create --partion 4 --replication-factor 2
上面是创建分区数为4，副本因子是2的主题。可以通过describe指令类型来查看分区副本的分配细节。
bin/kafka-topics.sh --zookeeper localhost:2181/kafka --describe --topic topic-create
上述创建主题的时候，分区副本都是按照既定的内部逻辑来进行分配的。kafka-topics.sh脚本还提供了一个replica-assignment参数来手动指定分区副本的分配方案。
bin/kafka-topics.sh --zookeeper localhost:2181/kafka --create --topic topic-create --replica-assignment 2:2,0:1,1:2,2:1
代表了主题中每个分区在broker的分配情况。
1.2、分区副本的分配
生产者的分区分配是指为每条消息指定其要发往的分区，消费者的分区分配是指为消费者指定其可以消费消息的分区，而这里的分区分配是指为集群指定创建主题时的分区分配方案，即在哪个broker中创建哪些分区的副本。
如果指定了replica-assignment参数，那么就按照指定的方案来进行分区副本的创建。如果没有使用，则按照内部分配逻辑来计算分区分配方案。
1.3、修改主题
当一个主题被创建后，依然允许我们进行一些修改，比如修改分区数量、修改配置等，都是通过alter指令完成。
bin/kafka-topics.sh --zookeeper localhost:2181/kafka --alter --topic topic-create --partition 3
比如上述的修改分区数量。不过要注意的是，分区数量修改之后，如果是key强相关的业务会受到影响，修改分区数量要谨慎。
目前kafak只支持增加分区数量，不支持减少分区数量，原因：
按照现在的代码逻辑，此功能完全可以实现，为什么不这样做。因为实现此功能需要考虑的因素太多。比如被删除的分区中的消息如何处理？如果随着分区一起消失则消息的可靠性得不到保障，如果需要保留怎么保留呢？如果直接存储到现有的分区尾部，消息的时间戳就不会递增，如此对于Spark这类需要时间戳的组建会受到影响，如果分散插入现有的分区，那么在消息量很大的时候，内部的数据复制会占用很大的资源，而且在复制期间，主题的可靠性怎么得到保障呢？因此，这个功能的收益点是很低的。
除了修改分区数，alter指令还可以修改主题的配置，比如修改max.message.bytes从10000修改到20000。
bin/kafka-topics.sh --zookeeper localhost:2181/kafka --alter --topic topic-create --config max.message.bytes=20000
2、分区的管理
Kafka虽然通过多副本机制来提高可靠性，但是Kafka只有leader副本负责读写，follower副本只负责在内部进行消息的同步。也就是说，Kafka并不实现类似redis、数据库等读写分离功能。
在创建分区的时候，分区的副本都会尽可能均匀分配到Kafka集群的各个节点上。对应的leader副本分配也会比较平均。Kafka集群的一个broker中最多只能有它的一个副本。
随着时间的更替，broker不可避免的会出现宕机的问题，当分区的broke节点发生故障的时候，其中一个follower节点就会成为新的leader节点，这样会导致集群的负载不均衡。（比如一个broker上的leader副本会多一些，其他broker上的leader副本少一些，毕竟只有leader节点负责读写，有的broker节点就会负载高一点）。
为了能有效得治理负载失衡的情况，Kafka引进了优先副本的概念。比如分区0的AR集合是[1,2,0]，那么分区0的优先副本就是broker1。理想情况下，优先副本就应该是leader副本。
所谓的优先副本选举就是通过一定的方式促使优先副本选举为leader副本，以此来达到集群的负载的均衡，也叫“分区平衡”。但是分区平衡并不意味着Kafka 集群的负载均衡，因为还要考虑到集群中的分区分配是否据哼。比如有的leader副本负载很高，TPS有3000多，有的很低。
这里很多内容不细究。。。。。。。。。。。。
3、如何选择合适的分区数
3.1、性能测试工具
生产者的性能测试工具kafka-producer-perf-test.sh，消费者性能测试工具kafka-consumer-perf-test.sh。
bin/kafka-producer-perf-test.sh --topic topic-test --num-records 100000 --record-size 1024 --throught 1 -- producer-props bootstrap.servers-localhost:9092 acks=1
上面就是测试生产者。打印的数据是：
502 records sent, 100.3records/sec(0.10 MB/sec), 2.5ms avg latency, 266.0 max lantcy
501 records sent, 99.5records/sec(0.10 MB/sec), 2.5ms avg latency, 266.0 max lantcy
可以看到发送数据的效率。
3.2、分区数越高吞吐量越高吗
理论上，如果一个主题中的分区数越多，理论上所能达到的吞吐量就越大。实际上不是这样的，会有一个阈值，超过这个阈值吞吐量反而会下降。
3.3、分区数的上限
如果创建1万个分区的主题，你会发现Kafka进程要崩溃。是内存不足吗，其实不是的，这点内存还不足以让Kafka“畏惧”。
我们会发现服务日志中出现大量的异常： Too many open files。
主要是受限于Linux系统文件描述符不足。
当然可以修改系统的文件描述符，具体不细究。
3.4、考量因素
从吞吐量考虑，增加合适的分区数可以在一定程度上提升吞吐量，但超过对应的阈值后吞吐量不升反降。如果对吞吐量有一定要求，则建议在投入生产环境之前做吞吐量相关的测试。
在创建topic之后，我们确实还可以增加分区数，但是基于key计算的主题需要谨慎对待。对于和key高关联的应用，在常见主题的时候可以适当去多创建一些分区，以备长远打算。
分区数的多少还会影响系统的可用性。分区在leader角色切换的过程中会变得不可用，不过对于单个分区来说这个过程非常短暂，但是如果集群中某个broker节点宕机，那么就会有大量的leader角色切换，这个切换过程会消耗很大一笔时间，并且在整个时间窗口内这些分区也会变得不可用。
如何选择合适的分区数？从某种意义上来说，要取决于实战经验，更透彻的说，是要从Kafka本身、业务使用、硬件资源等等方面综合考虑。一般情况下，根据吞吐量以及是否与key相关的规则来设定分区数即可，后期可以增加分区数、增加broker或分区重分配手段来进行改造。如果有一定准则，建议将分取设定为broker数量的倍数。
4、问题
当所有ISR副本都不可用时，kafka会怎样？unclean.leader.election.enable参数，默认为false，表示选举leader副本是否必须从ISR中选择，默认是必须。参考文章：https://blog.csdn.net/u013256816/article/details/80790185
