参数调优 修改服务配置参数，请参考修改集群服务配置参数。调优参数请参考表1。 表1 调优参数 配置参数 缺省值 调优场景 num.recovery.threads.per.data.dir 10 在Kafka启动过程中，数据量较大情况下，可调大此参数，可以提升启动速度。 background.threads 10 Broker后台任务处理的线程数目。数据量较大的情况下，可适当调大此参数，以提升Broker处理能力。 num.replica.fetchers 1 副本向Leader请求同步数据的线程数，增大这个数值会增加副本的I/O并发度。 num.io.threads 8 Broker用来处理磁盘I/O的线程数目，这个线程数目建议至少等于硬盘的个数。 KAFKA_HEAP_OPTS -Xmx6G -Xms6G Kafka JVM堆内存设置。当Broker上数据量较大时，应适当调整堆内存大小。

前提条件 使用Kafka客户端时：已安装客户端，例如安装目录为“/opt/client”，以下操作的客户端目录只是举例，请根据实际安装目录修改。 使用KafkaUI时：已创建具有KafkaUI页面访问权限的用户，如需在页面上进行相关操作，例如创建Topic，需同时授予用户相关权限，请参考Kafka用户权限说明。 第一次访问Manager和KafkaUI，需要在浏览器中添加站点信任以继续访问KafkaUI。

Topic和Partition的划分关系说明 假设集群中部署了K个Kafka节点，每个节点上配置的磁盘个数为N，每块磁盘大小为M，集群共有n个Topic（T1,T2…Tn），并且其中第m个Topic的每秒输入数据总流量为X(Tm) MB/s，配置的副本数为R(Tm)，配置数据保存时间为Y(Tm)小时，那么整体必须满足： 假设单个磁盘大小为M，该磁盘上有n个Partition（P0,P1……Pn），并且其中第m个Partition的每秒写入数据流量为Q(Pm) MB/s（计算方法：所属Topic的数据流量除以Partition数） 、数据保存时间为T(Pm)小时，那么单个磁盘必须满足： 根据吞吐量粗略计算，假设生产者可以达到的吞吐量为P，消费者可以达到的吞吐量为C，预期Kafka吞吐量为T，那么建议该Topic的Partition数目设置为Max(T/P , T/C)。 在Kafka集群中，分区越多吞吐量越高，但是分区过多也存在潜在影响，例如文件句柄增加、不可用性增加（如：某个节点故障后，部分Partition重选Leader后时间窗口会比较大）及端到端时延增加等。 建议：单个Partition的磁盘占用最大不超过100GB；单节点上Partition数目不超过3000；整个集群的分区总数不超过10000。

启动Maxwell 登录Maxwell所在的服务器。 执行如下命令进入Maxwell安装目录。 cd /opt/maxwell-1.21.0/ 如果是初次使用Maxwell，建议将conf/config.properties中的log_level改为debug(调试级别)，以便观察启动之后是否能正常从MySQL获取数据并发送到kafka，当整个流程调试通过之后，再把log_level修改为info，然后先停止再启动Maxwell生效。 # log level [debug | info | warn | error] log_level=debug 执行如下命令启动Maxwell。 source /opt/client/bigdata_env bin/Maxwell bin/maxwell --user='maxwell' --password='XXXXXX' --host='127.0.0.1' \ --producer=kafka --kafka.bootstrap.servers=kafkahost:9092 --kafka_topic=Maxwell 其中，user，password和host分别表示MySQL的用户名，密码和IP地址，这三个参数可以通过修改配置项配置也可以通过上述命令配置，kafkahost为流式集群的Core节点的IP地址。 命令中如果携带认证密码信息可能存在安全风险，在执行命令前建议关闭系统的history命令记录功能，避免信息泄露。 显示类似如下信息，表示Maxwell启动成功。 Success to start Maxwell [78092].

Maxwell生成的数据格式及常见字段含义 Maxwell生成的数据格式为JSON，常见字段含义如下： type：操作类型，包含database-create，database-drop，table-create，table-drop，table-alter，insert，update，delete database：操作的数据库名称 ts：操作时间，13位时间戳 table：操作的表名 data：数据增加/删除/修改之后的内容 old：数据修改前的内容或者表修改前的结构定义 sql：DDL操作的SQL语句 def：表创建与表修改的结构定义 xid：事务唯一ID commit：数据增加/删除/修改操作是否已提交

验证Maxwell 登录Maxwell所在的服务器。 查看日志。如果日志里面没有ERROR日志，且有打印如下日志，表示与MySQL连接正常。 BinlogConnectorLifecycleListener - Binlog connected. 登录MySQL数据库，对测试数据进行更新/创建/删除等操作。操作语句可以参考如下示例。 -- 创建库 create database test; -- 创建表 create table test.e ( id int(10) not null primary key auto_increment, m double, c timestamp(6), comment varchar(255) charset 'latin1' ); -- 增加记录 insert into test.e set m = 4.2341, c = now(3), comment = 'I am a creature of light.'; -- 更新记录 update test.e set m = 5.444, c = now(3) where id = 1; -- 删除记录 delete from test.e where id = 1; -- 修改表 alter table test.e add column torvalds bigint unsigned after m; -- 删除表 drop table test.e; -- 删除库 drop database test; 观察Maxwell的日志输出，如果没有WARN/ERROR打印，则表示Maxwell安装配置正常。 若要确定数据是否成功上传，可设置config.properties中的log_level为debug，则数据上传成功时会立刻打印如下JSON格式数据，具体字段含义请参考Maxwell生成的数据格式及常见字段含义。 {"database":"test","table":"e","type":"insert","ts":1541150929,"xid":60556,"commit":true,"data":{"id":1,"m":4.2341,"c":"2018-11-02 09:28:49.297000","comment":"I am a creature of light."}} …… 当整个流程调试通过之后，可以把config.properties文件中的配置项log_level修改为info，减少日志打印量，并重启Maxwell。 # log level [debug | info | warn | error] log_level=info

配置Maxwell 在maxwell-XXX文件夹下若有conf目录则配置config.properties文件，配置项说明请参见表1。若没有conf目录，则是在maxwell-XXX文件夹下将config.properties.example修改成config.properties。 表1 Maxwell配置项说明 配置项 是否必填 说明 默认值 user 是 连接MySQL的用户名，即2中新创建的用户 - password 是 连接MySQL的密码，配置文件中包含认证密码信息可能存在安全风险，建议当前场景执行完毕后删除相关配置文件或加强安全管理。 - host 否 MySQL地址 localhost port 否 MySQL端口 3306 log_level 否 日志打印级别，可选值为 debug info warn error info output_ddl 否 是否发送DDL(数据库与数据表的定义修改)事件 true：发送DDL事件 false：不发送DDL事件 false producer 是 生产者类型，配置为kafka stdout：将生成的事件打印在日志中 kafka：将生成的事件发送到kafka stdout producer_partition_by 否 分区策略，用来确保相同一类的数据写入到kafka同一分区 database：使用数据库名称做分区，保证同一个数据库的事件写入到kafka同一个分区中 table：使用表名称做分区，保证同一个表的事件写入到kafka同一个分区中 database ignore_producer_error 否 是否忽略生产者发送数据失败的错误 true：在日志中打印错误信息并跳过错误的数据，程序继续运行 false：在日志中打印错误信息并终止程序 true metrics_slf4j_interval 否 在日志中输出上传kafka成功与失败数据的数量统计的时间间隔，单位为秒 60 kafka.bootstrap.servers 是 kafka代理节点地址，配置形式为HOST:PORT[,HOST:PORT] - kafka_topic 否 写入kafka的topic名称 maxwell dead_letter_topic 否 当发送某条记录出错时，记录该条出错记录主键的kafka topic - kafka_version 否 Maxwell使用的kafka producer版本号，不能在config.properties中配置，需要在启动命令时用-- kafka_version xxx参数传入 - kafka_partition_hash 否 划分kafka topic partition的算法，支持default或murmur3 default kafka_key_format 否 Kafka record的key生成方式，支持array或Hash Hash ddl_kafka_topic 否 当output_ddl配置为true时，DDL操作写入的topic {kafka_topic} filter 否 过滤数据库或表。 若只想采集mydatabase的库，可以配置为 exclude: *.*,include: mydatabase.* 若只想采集mydatabase.mytable的表，可以配置为 exclude: *.*,include: mydatabase.mytable 若只想采集mydatabase库下的mytable，mydate_123, mydate_456表，可以配置为 exclude: *.*,include: mydatabase.mytable, include: mydatabase./mydate_\\d*/ -

安装Maxwell 下载安装包，下载路径为https://github.com/zendesk/maxwell/releases，选择名为maxwell-XXX.tar.gz的二进制文件下载，其中XXX为版本号。 将tar.gz包上传到任意目录下（本示例路径为Master节点的/opt）。 登录部署Maxwell的服务器，并执行如下命令进入tar.gz包所在目录。 cd /opt 执行如下命令解压“maxwell-XXX.tar.gz”压缩包，并进入“maxwell-XXX”文件夹。 tar -zxvf maxwell-XXX.tar.gz cd maxwell-XXX

原因分析 用户反馈已经排查了执行此命令的账号权限，此账号具有操作Kafka组件的最高权限，不应该仍然会有权限不足的问题。 经确认执行命令有问题，访问ZooKeeper上所存放的Kafka信息，其路径（Znode）应该加上/kafka，完整的查询命令应该是： root@Slave2bin]#./kafka-topics.sh --describe --topic example-metric1 --zookeeper 192.168.147.231:2181,192.168.147.228:2181,192.168.147.227:2181/kafka

问题背景与现象 当数据量较大时会频繁的发生rebalance导致出现重复消费的情况，关键日志如下： 2018-05-12 10:58:42,561 | INFO | [kafka-request-handler-3] | [GroupCoordinator 2]: Preparing to restabilize group DemoConsumer with old generation 118 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 10:58:43,245 | INFO | [kafka-request-handler-5] | [GroupCoordinator 2]: Stabilized group DemoConsumer generation 119 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 10:58:43,560 | INFO | [kafka-request-handler-7] | [GroupCoordinator 2]: Assignment received from leader for group DemoConsumer for generation 119 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 10:59:13,562 | INFO | [executor-Heartbeat] | [GroupCoordinator 2]: Preparing to restabilize group DemoConsumer with old generation 119 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 10:59:13,790 | INFO | [kafka-request-handler-3] | [GroupCoordinator 2]: Stabilized group DemoConsumer generation 120 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 10:59:13,791 | INFO | [kafka-request-handler-0] | [GroupCoordinator 2]: Assignment received from leader for group DemoConsumer for generation 120 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 10:59:43,802 | INFO | [kafka-request-handler-2] | Rolled new log segment for '__consumer_offsets-17' in 2 ms. | kafka.log.Log (Logging.scala:68) 2018-05-12 10:59:52,456 | INFO | [group-metadata-manager-0] | [Group Metadata Manager on Broker 2]: Removed 0 expired offsets in 0 milliseconds. | kafka.coordinator.GroupMetadataManager (Logging.scala:68) 2018-05-12 11:00:49,772 | INFO | [kafka-scheduler-6] | Deleting segment 0 from log __consumer_offsets-17. | kafka.log.Log (Logging.scala:68) 2018-05-12 11:00:49,773 | INFO | [kafka-scheduler-6] | Deleting index /srv/BigData/kafka/data4/kafka-logs/__consumer_offsets-17/00000000000000000000.index.deleted | kafka.log.OffsetIndex (Logging.scala:68) 2018-05-12 11:00:49,773 | INFO | [kafka-scheduler-2] | Deleting segment 2147948547 from log __consumer_offsets-17. | kafka.log.Log (Logging.scala:68) 2018-05-12 11:00:49,773 | INFO | [kafka-scheduler-4] | Deleting segment 4282404355 from log __consumer_offsets-17. | kafka.log.Log (Logging.scala:68) 2018-05-12 11:00:49,775 | INFO | [kafka-scheduler-2] | Deleting index /srv/BigData/kafka/data4/kafka-logs/__consumer_offsets-17/00000000002147948547.index.deleted | kafka.log.OffsetIndex (Logging.scala:68) 2018-05-12 11:00:49,775 | INFO | [kafka-scheduler-4] | Deleting index /srv/BigData/kafka/data4/kafka-logs/__consumer_offsets-17/00000000004282404355.index.deleted | kafka.log.OffsetIndex (Logging.scala:68) 2018-05-12 11:00:50,533 | INFO | [kafka-scheduler-6] | Deleting segment 4283544095 from log __consumer_offsets-17. | kafka.log.Log (Logging.scala:68) 2018-05-12 11:00:50,569 | INFO | [kafka-scheduler-6] | Deleting index /srv/BigData/kafka/data4/kafka-logs/__consumer_offsets-17/00000000004283544095.index.deleted | kafka.log.OffsetIndex (Logging.scala:68) 2018-05-12 11:02:21,178 | INFO | [kafka-request-handler-2] | [GroupCoordinator 2]: Preparing to restabilize group DemoConsumer with old generation 120 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 11:02:22,839 | INFO | [kafka-request-handler-4] | [GroupCoordinator 2]: Stabilized group DemoConsumer generation 121 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 11:02:23,169 | INFO | [kafka-request-handler-1] | [GroupCoordinator 2]: Assignment received from leader for group DemoConsumer for generation 121 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 11:02:49,913 | INFO | [kafka-request-handler-6] | Rolled new log segment for '__consumer_offsets-17' in 2 ms. | kafka.log.Log (Logging.scala:68) 其中Preparing to restabilize group DemoConsumer with old generation表示正在发生rebalance。

原因分析 原因：由于参数设置不当，数据量大时数据处理时间过长，导致频繁发生balance，此时offset无法正常提交，导致重复消费数据。 原理：每次poll的数据处理完后才提交offset，如果poll数据后的处理时长超出了session.timeout.ms的设置时长，此时发生rebalance导致本次消费失败，已经消费数据的offset无法正常提交，所以下次重新消费时还是在旧的offset消费数据，从而导致消费数据重复。

解决办法 建议用户在Manager页面调整以下服务参数： request.timeout.ms=100000 session.timeout.ms=90000 max.poll.records=50 heartbeat.interval.ms=3000 其中： request.timeout.ms要比session.timeout.ms大10s。 session.timeout.ms的大小设置要在服务端参数group.min.session.timeout.ms和group.max.session.timeout.ms之间。 以上参数可以根据实际情况进行适当的调整，特别是max.poll.records，这个参数是为了控制每次poll数据的records量，保证每次的处理时长尽量保持稳定。目的是为了保证poll数据以后的处理时间不要超过session.timeout.ms的时间。