Kafka-最佳实践之-Broker-性能调优（一）
通过扩展节点资源，来达到千万TPS等海量吞吐诉求，实际上，我们大部分业务可能不需要那么大规模，对于集群资源有限，如何最大可能调优kafka集群性能，下面我们从broker、producer、consumer 3个方面性能相关参数详细解析，实测解密集群如何最大性能化
网络模型相关参数
关于kafka网络模型的原理请查看上一篇博客：Kafka 源码解析之 Server 1+N+M 网络处理模型（一）
参数描述
| 参数 | 默认值 | 说明 |
|---|---|---|
| num.network.threads | 3 | Broker用来处理网络请求的网络线程数目；主要处理网络io，读写缓冲区数据，基本没有io等待，配置线程数量为cpu核数加1. |
| num.io.threads | 8 | broker用来处理请求的I/O线程的数目；主要进行磁盘io操作，高峰期可能有些io等待，因此配置需要大些。配置线程数量为cpu核数2倍，最大不超过3倍 |
| queued.max.requests | 500 | 在网络线程停止读取新请求之前，可以排队等待I/O线程处理的最大请求个数;超过该值，network thread阻塞 |
Kafka网络通信层的完整框架图如下图所示：
Kafka使用NIO自己实现了网络层的代码， 而不是采用netty, mina等第三方的网络框架。从性能上来讲，这一块的代码不是性能的瓶颈。
它采用IO多路复用和多线程下的Reactor模式,主要实现类包括SocketServer, Acceptor, Processor和RequestChannel。
Kafka的服务器由SocketServer实现,它是一个NIO的服务器，线程模型如下：
1个Acceptor线程负责处理新连接N个Processor线程， 每个processor都有自己的selector，负责从socket中读取请求和发送responseM个Handler线程处理请求，并产生response给processor线程
可以从上面的图形中看到Acceptor, Processor和Handler的功能
其中num.network.threads是控制上图中的Processor Thread的个数， num.io.threads是控制API Thread的个数，queued.max_requests是控制Request Channel队列的容量
日志保存策略
| 参数 | 默认值 | 说明 |
|---|---|---|
| log.retention.hours | 168 | 当kafka broker的被写入海量消息后，会生成很多数据文件，占用大量磁盘空间，kafka默认是保留7天，建议根据磁盘情况配置，避免磁盘撑爆 |
| log.segment.bytes | 1GB | 段文件配置1GB，有利于快速回收磁盘空间，重启kafka加载也会加快(如果文件过小，则文件数量比较多，kafka启动时是单线程扫描目录(log.dir)下所有数据文件) |
Replica 副本配置
| 参数 | 默认值 | 推荐值 | 说明 |
|---|---|---|---|
| replica.socket.receive.buffer.bytes | 64*1024 | 256k~2M | 备份时向leader发送网络请求时的socket receive buffer |
| replica.fetch.max.bytes | 1024*1024 | 根据业务实际配置 | 备份时每次fetch的最大值 |
| num.replica.fetchers | 1 | 默认值 | 从leader备份数据的线程数 |
- replica.socket.receive.buffer.bytes： 同TCP buffer的分析，不少于BDP 窗口大小，时延高的可以设大一点
replica.fetch.max.bytes: 不得少于发往broker消息的最大长度（message.max.bytes），需要根据业务实际消息的大小，然后设大一点即可。
num.replica.fetchers： 复制fetch线程设置大一点可以提升获取性能，同时增加备机的IO并行性，但设置太大也没用反而导致空闲，这个同Consumer的fetch thread一样。
在ACK=1的情况下，Produce/Consumer的性能与复制关系不是很大，除非受到网络的瓶颈
参考