一:Kafka分区数计算:

（1）创建一个只有1个分区的topic

（2）测试这个topic的producer吞吐量和consumer吞吐量。

（3）假设他们的值分别是Tp和Tc，单位可以是MB/s。

（4）然后假设总的目标吞吐量是Tt，那么分区数 = Tt / min（Tp，Tc）

例如：producer吞吐量 = 20m/s；consumer吞吐量 = 50m/s，期望吞吐量100m/s；

分区数 = 100 / 20 = 5分区

经验总结:分区数一般设置为3-10个

二:Kafka常用命令总结:

1）查看Kafka Topic列表

bin/kafka-topics.sh --zookeeper hadoop102:2181/kafka --list

 2）创建Kafka Topic

进入到/opt/module/kafka/目录下创建日志主题

bin/kafka-topics.sh --zookeeper hadoop102:2181,hadoop103:2181,
hadoop104:2181/kafka  --create --replication-factor 1 --partitions 1 
--topic topic_log

3）删除Kafka Topic

bin/kafka-topics.sh --delete --zookeeper hadoop102:2181,hadoop103:2181,
hadoop104:2181/kafka --topic topic_log

4）Kafka生产消息

bin/kafka-console-producer.sh \
--broker-list hadoop102:9092 --topic topic_log
>hello world

5）Kafka消费消息

bin/kafka-console-consumer.sh \
--bootstrap-server hadoop102:9092 --from-beginning --topic topic_log

--from-beginning：会把主题中以往所有的数据都读取出来。根据业务场景选择是否增加该配置。

6）查看Kafka Topic详情

bin/kafka-topics.sh --zookeeper hadoop102:2181/kafka \
--describe --topic topic_log

三:Kafka的分区数是不是越多越好？

3.1 分区多的优点
Kafka使用分区将topic的消息打算到多个分区分布保存在不同的broker上，实现了producer和consumer消息处理的高吞吐量。
Kafka的producer和consumer都可以多线程地并行操作，而每个线程处理的是一个分区的数据。
因此分区实际上是调优Kafka并行度的最小单元。
对于producer而言，它实际上是用多个线程并发地向不同分区所在的broker发起socket连接，同时给这些分区发送消息。
对于consumer，同一个消费组内的所有consumer线程都被指定topic的某一个分区进行消费。
所以说，如果一个topic分区越多，理论上整个集群所能达到的吞吐量就约到
3.2 分区不是越多越好
分区是否越多越好呢？显然也不是，因为每个分区都有自己的开销：
一、分区越多，客户端/服务器端需要使用的内存就越多
producer

Kafka0.8.2之后，在客户端producer有个参数batch.size，默认是16KB。它会为每个分区缓存消息（每个分区缓存默认16KB）。一旦满了就打包将消息批量发出。
如果分区越多，这部分缓存所需的内存占用也会更多。
假设你有10000个分区，按照默认设置，生产端这部分缓存需要占用约157MB的内存(16*10000/157)。
consumer

抛开获取数据所需的内存不说，只说线程的开销。
如果还是假设10000个分区，同时consumer线程数要匹配分区数（大部分情况下是最佳的消费吞吐量配置）的话，在consumer client就要创建10000个线程，也需要创建大约10000个socket去获取分区数据。
线程切换的开销本身已经不容小觑了。
服务器

服务器的开销也不小，如果阅读kafka源码的话可以发现，服务器端的很多组件都在内存中维护了分区级别的缓存。
比如controller,FetcherManager等，因此分区数越多，这种缓存的成本就越大。
二、分区越多，文件句柄的开销越多

每个分区在底层文件系统都有属于自己的一个目录。该目录下通常会有两个文件：base_offset.log和base_offset.index。
Kakfa的controller和ReplicaManager会为每个broker都保存这两个文件句柄（file handler）。
如果分区数越多，所需要保持打开状态的文件句柄数也就越多，最终可能会突破你的ulimit-n的限制。
三、分区越多，会降低高可用性

Kafka通过副本（replica）机制来保证高可用。
具体做法就是为每个分区保存若干个副本（replica_factor指定副本数）。
每个副本保存在不同的broker上，其中一个副本充当leader副本，负责处理producer和consumer请求，其他副本充当follower角色，由Kafka controller负责保证与leader的同步。
如果leader所在的broker挂掉了，controller会检测到然后在zookeeper的帮助下重新选出新的leader–这中间会有短暂的不可用时间窗口。
虽然大部分情况下可能只有几毫秒级别，但是如果你有10000个分区，10个broker，也就是平均每个broker上有1000个分区。此时broker挂掉了，那么zookeeper和controller需要立即对这1000个分区进行leader选举。
比起很少的分区leader选举而言，多个分区的选举要花更长的时间，并且通常不是线性累加的。