一个专注于运维领域的个人技术博客

上篇文章我们了解到，如果一个topic分区越多，理论上整个集群所能达到的吞吐量就越大。那么，分区数越多就越好吗？显然不是。今天我们来聊下kafka在分区数过多的情况下，会带来哪些弊端。

内存开销

客户端producer有个参数batch.size默认为16KB。它会为每个分区缓存消息，一旦批次数满了后，将消息批量发出。一般来说，这个设计是用于提升吞吐性能的。但是由于这个参数是partition级别的，如果分区数越多，这部分缓存所需的内存占用也会越多。假如有10000个分区，按照默认配置，这部分缓存就要占用约157MB的内存。而consumer端呢？抛开拉取数据所需的内存不说，单说线程的开销。如果还是10000个分区，同时consumer线程数要匹配分区数的话(大部分情况下是最佳的消费吞吐量配置)，那么在consumer client就要创建10000个线程，也需要创建大约10000个Socket去获取分区数据，这里面的线程切换的开销本身就已经不容小觑了。
服务器端的开销也不小，如果阅读kafka源码的话就会发现，服务器端的很多组件在内存中维护了partition级别的缓存，比如controller，FetcherManager等，因此分区数越多，这种缓存的成本就越大。

分区(partition)概念

要讲kafka分区数和吞吐量的关系，首先得理解什么是分区(partition)。

Partition是作用于具体的Topic而已的，而不是一个独立的概念。Partition能水平扩展客户端的读写性能，是高吞吐量的保障。通俗的讲，Partition就是一块保存具体数据的空间，本质就是磁盘上存放数据的文件夹，所以Partition是不能跨Broker存在的，也不能在同一个Broker上跨磁盘。对于一个Topic，可以根据需要设定Partition的个数。数据持久化时，每条消息都是根据一定的分区规则路由到对应的Partition中，并append在log文件的尾部(这一点类似于HDFS)，如上图；在同一个Partition中消息是顺序写入的且始终保持有序性；但是不同Partition之间不能保证消息的有序性(高吞吐量的保障)。kafka就是通过使用分区的设计将topic的消息打散到多个分区分布保存在不同的broker上，实现了producer和consumer消息处理的高吞吐量。

生产环境kafka集群，在数据量大的情况下，会出现单机各个磁盘间的占用不均匀情况，经常出现“一边倒”的情形。

原因探究

这是因为kafka只保证分区数量在各个磁盘上均匀分布，但它无法统计每个分区实际占用磁盘空间。因此很有可能出现某些分区消息数量巨大导致占用大量磁盘空间的情况。在1.1版本之前，用户对此基本没有优雅的处理方法，即便手动迁移日志文件和offset信息，也需要重启生效，风险极高。因为1.1之前kafka只支持分区数据在不同broker间的重分配，而无法做到在同一个broker下的不同磁盘间做重分配。1.1版本正式支持副本在不同路径间的迁移，具体的实现细节详见kafka官方wikiKIP-113。

目录间迁移步骤

假设我在server.properties文件中配置了多个日志存储路径(代表多块磁盘)，如下所示：

1
2
3

# A comma seperated list of directories under which to store log files
log.dirs=/data1/kafka-logs,/data2/kafka-logs,/data3/kafka-logs

生产环境的kafka集群扩容，是一个比较常见的需求和操作。然而kafka在新增节点后并不会像elasticsearch那样感知到新节点加入后，自动将数据reblance到整个新集群中，因此这个过程需要我们手动分配。

分区重分配方案

扩容后的数据均衡，其本质就是对topic进行分区重分配，数据迁移的过程。
在执行分区重分配的过程中，对集群的影响主要有两点：

1. 分区重分配主要是对topic数据进行Broker间的迁移，因此会占用集群的带宽资源；
2. 分区重分配会改变分区Leader所在的Broker，因此会影响客户端。

通过之前一系列的文章叙述，想必大家都对dr.elephant有了一个较为清晰的了解。通过自己线上经验的积累，以及和一些读者的交流，我汇总了一些大家在实战中遇到的问题和解决方案。

常规问题

由于在和读者交流的过程中，发现大家技术水平参差不齐，本着科普性文章的初衷，这里先讲一些比较基础的要点，大佬们可以忽略，直接跳过。

1. 在打包时，需要对照自己的Hadoop或者Spark版本，修改compile.conf文件中的版本号。否则有可能出现采集不到集群作业信息的情况。
2. 最好将自己Hadoop集群的相关配置文件都拷贝到dr.elephant的app-conf目录下。
3. 统一自己Hadoop集群的环境变量。

数据库问题

Database ‘default’ is in an inconsistent state!

启动失败并出现这个报错，一般是play框架的evolution问题，解决方法如下：

1. 停止dr.elephant并确保进程已kill
2. 删除原来的数据库并重新建库
3. 配置app-conf/elephant.conf中jvm_props="-Devolutionplugin=enabled -DapplyEvolutions.default=true"，开启evolution，使其能够自动初始化表结构。