Kafka使用最佳实践-Kafka集群部署规范

Kafka集群部署规范

1.CPU规格与挂盘数量的关系规范

根据FusionInsight HD产品文档中所述的硬件要求来选择合适的部署方式。对于kafka组件需要关注机器中具体处理器超线程个数，即processor的个数，可以通过命令：grep -c processor /proc/cpuinfo 查看。这个参数代表了整个机器的处理能力，kafka默认，建议：每台机器最大挂盘数量 <= processor / 2

例如：机器的processor数量为24，那么这个机器的最大挂盘数为12块。

2.磁盘挂载规范

Kafka在1.x版本（FI对应版本为6.5.x）之前，对于磁盘容错方面做的不够完善，如果单台节点如果出现一块磁盘故障，那么这个节点的kafka进程就会出现异常，因此，不建议每个broker节点挂载多个单盘。

使用建议：建议每台机器使用raid5来挂载磁盘。单台机器可以挂载多个raid5的逻辑盘，每块逻辑盘的物理盘个数可以按照需求指定。

3.Topic创建规范

kafka的一个topic通常代表了一类数据，合理的创建topic是保持kafka集群健壮的基本因素。 标准的topic使用建议如下：

不可无休止的创建而不删除topic。kafka集群的topic数量（或者说topic的分区总量）有一定限，上限根据集群的性能而定。一旦整个集群的分区总量到达上限，会导致kafka集群无法正常服务，建议集群中topic总量不超过2000，每个节点的分区总量不超过2000。

使用建议：如果业务重要或者数据量很大，建议分区量=节点数*磁盘数，如果该数值大于200，则分区数选择为200，如果后期需要需要提升分区数来提升读写性       能，可以使用kafka后台命令逐步提升，如果数据量很小，建议分区量=节点数，保证每个节点的数据量均衡。

b.副本数不可配太多。副本是kafka容错能力的基础，当kafka出现节点故障后，另外的副本会承担leader接收数据责任。副本数增加一个，就需要多一次数据同步，也会使 kafka节点之间的数据流量同步能加一次。如果副本太多会。导致leader节点的数据流量压力增加。

使用建议：创建的topic有2~3备份即可。

c. 机架参数要合理使用。FusionInsight-HD中的kafka集群默认使用了机架感知策略，即：保证kafka所创建的topic的分区副本在不同的机架上面，这样能够保证如果出现机架宕机后，kafka依然有可用的副本。但是如果集群中每个机架上面的节点数量不均衡，会导致严重的数据倾斜。例如：kafka总共有2个机架10台机器，如果一个机架上有3个节点，一个机架上面有7个节点，那么3节点机架上的机器的副本数一定大于7节点机架的。

使用建议：如果kafka集群的机器在每个机架上面分布不均衡，在创建topic的时候加入机架不感知参数。

创建方式如下,其中ZK_IP为集群zookeeper的ip:

kafka-topics.sh --create --topic --partitions --replication-factor --zookeeper --disable-rack-aware

d. 不可频繁的创建删除topic。topic的创建目的应该是一次创建，长时间使用，如果topic出现异常可以删除重建。如果频繁创建，会导致broker节点异常，topic无法正常删除，同时对zookeeper也会造成一定的压力（频繁的创建删除，也就是频繁的增删zookeeper上面的节点，如果频率很大容易导致“羊群效应”和“脑裂”）。例如：每天大批量的创建删除1000个。

使用建议：

如果有删除topic需要。每天删除量不建议超过10个。

规整数据的协议类型，将多个相同类型的数据合并到一个topic中，创建后长期使用。防止出现topic频繁创建删除的情形。

4.集群性能调优

Kafka的集群调优通常考虑维度主要有两个，第一，是磁盘读写能力，第二，网络带宽。

磁盘的读写的负载可以通过命令：iostat –x -1 查看 idle指标，这个值越大代表磁盘越空闲。万兆网卡的极限能力为1250M/s，网络速度可以通过前台界面的，主机管理->对应主机“网络写入速度”，“网络读取速度”获取。通常在性能的极限情况下，磁盘io会成为性能瓶颈。Kafka侧优化写入性能的参数如下：

配置项

缺省值

调优场景

num.recovery.threads.per.data.dir

10

每个数据目录用来数据恢复的线程数目。在Kafka启动过程中，数据量较大情况下，可调大此参数，可以提升启动速度。

background.threads

10

Broker后台任务处理的线程数目。数据量较大的情况下，可适当调大此参数，以提升Broker处理能力。

num.replica.fetchers

1

副本向Leader请求同步数据的线程数。增大这个数值会增加副本的I/O并发度。

num.network.threads

3

Broker用来处理网络请求的线程数目

num.io.threads

8

Broker用来处理磁盘I/O的线程数目。这个线程数目建议至少等于硬盘的个数。

queued.max.requests

500

指定用于缓存网络请求的队列的最大容量，这个队列达到上限之后将不再接收新请求。

在网络线程停止读取新请求之前，可以排队等待I/O线程处理的最大请求个数。增大queued.max.requests能够缓存更多的请求，以撑过业务峰值。如果过大，会造成内存的浪费。

socket.receive.buffer.bytes

102400

服务端接收缓冲区大小，增加该参数能够提升生产、消费数据在缓冲区的数量，从而提升网络传输的吞吐量

socket.send.buffer.bytes

102400

服务端发送缓冲区大小，增加该参数能够提升生产、消费数据在缓冲区的数量，从而提升网络传输的吞吐量

replica.socket.receive.buffer.bytes

65536

备份时向leader发送网络请求时的socket receive buffer

replica.lag.max.messages

4000

如果一个副本中没有同步的消息条数超过这个数值，Leader会认为该副本已经失效，并将其从ISR中移除。

KAFKA_HEAP_OPTS

-Xmx6G -Xms6G

Kafka内存占用参数配置。

kafka集群的性能参数调整到最优值后，kafka数据的处理能力会大幅度提升cpu的使用率也会增加。如果后续节点上的数据流量持续增长，CPU的使用率也会上升。

5. Kafka性能维度标准

5.1性能维度

6.5.1版本之后kafka生产者的性能基线标准

如何判断一个kafka集群是否已经处于性能瓶颈，通常的判断条件有如下几点：

维度1：磁盘IO

读写磁盘性能是kafka重要的参数指标，如果磁盘IO到达性能瓶颈会直接导致业务故障。Kafka读写性能跟磁盘IO之间的关系计算如下：

举例：假设磁盘IO的上限为100M/s，数据大小为8k，假设在topic仅设置为单副本的情况下，理论上一块盘能写入的数据量为100*1024/8=12800条。如果一个节点挂载4块盘，那么理论性能为4*12800条。如果kafka集群有4个节点，那么整个集群的性能为4*4*12800条。

维度2：网络IO

现网的网卡设置一般为万兆网卡，一张万兆网卡的理论极限性能为1250MB/s，在多kafka集群场景下，如果每个节点的数据流量不超过这个值，网卡一般不会出现性能瓶颈。

维度3：CPU使用率

Kafka使用CPU的地方主要在请求的处理、数据落盘等，如果CPU使用率频繁出现95%以上的情况表示kafka集群性能已经到达瓶颈。通常影响kafka集群CPU使用率的几个参数主要有以下几个：

num.recovery.threads.per.data.dir，background.threads，num.replica.fetchers，num.network.threads，num.io.threads。具体参数含义见1.4章节。在磁盘和网卡未达到瓶颈的前提下，如果CPU使用率未达到上限，可以适当调大num.io.threads和num.network.threads，以提升kafka的集群处理能力。

以上三个性能指标哪个先达到瓶颈就是kafka集群的瓶颈。

5.2接口基线性能

异步producer性能数据

message.size

batch.size

total.data.sent.in.MB

MB.sec

total.data.sent.in.nMsg

nMsg.sec

50

200

4768.37

64.4671

99999984

1351972.3116

100

200

9536.74

120.8835

99999984

1267555.4429

150

200

14305.11

231.6430

99999984

1619301.8217

200

200

19073.48

187.9179

99999984

985231.2240

512

200

48828.12

391.3607

99999984

801506.7046

1024

200

97656.23

539.1827

99999984

552123.1014

2048

200

1953.09

249.6924

999984

127842.4955

随着消息大小变大，吞吐量增加，每秒处理的消息条数逐渐变少。

同步producer性能数据

message.size

batch.size

total.data.sent.in.MB

MB.sec

total.data.sent.in.nMsg

nMsg.sec

50

200

476.84

2.9943

9999984

62795.0367

100

200

953.67

5.8847

9999984

61705.8232

150

200

1430.51

8.6639

9999984

60565.2198

200

200

1907.35

11.1892

9999984

58663.6631

512

200

4882.80

28.0556

9999984

57457.9637

1024

200

9765.61

49.8378

9999984

51033.8661

2048

200

19531.22

77.4646

9999984

39661.8583

Producer同步发送的性能每秒在6万条左右。

Consumer性能数据

Batch-size

fetch.size

data.consumed.in.MB

MB.sec

data.consumed.in.nMsg

nMsg.sec

50

1048576

9536.7416

185.8833

99999984

1949127.5

100

1048576

9536.7416

215.0142

99999984

2254587.7

200

1048576

9536.7416

180.381

99999984

1891431.5

500

1048576

9536.7416

195.9712

99999984

2054906.8

1000

1048576

9536.7416

197.8167

99999984

2074258.1

2000

1048576

9536.7416

194.8103

99999984

2042733.7

5000

1048576

9536.7416

232.1053

99999984

2433800.2

100000

1048576

9536.7416

195.5372

99999984

2050356.4

100000

1048576

9536.7416

227.2059

99999984

382426.84

随着Batch-size增加，消费者每秒消费的消息条数增加。以上场景的硬件信息如下：

硬件配置如下：

l   CPU：32core 2.0GHZ

l   内存：128G

l   硬盘：2*（SAS OS盘）+12*2.7T（SATA）

l   Broker节点数：2个

l Kafka使用的配置：num.io.thread=8

其它场景下，异步模式下生产、消费性能基线见附件：性能基线-kafka

EI企业智能 FusionInsight Kafka

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。