CDC事件高效流转的关键参数

本文针对海量binlog事件处理场景，列出让事件流能够高效处理的关键参数

CDC事件处理流程图

下图描绘了使用canal或者flink cdc，采集binlog并处理、保存到clickhouse的过程；
建议从slave节点采集binlog，避免增大master传输压力

mysql参数

binlog-row-event-max-size

mariadb只能在启动文件里配置此参数，用于控制一行binlog的大小，建议不大于1M。
一行binlog可能包含一条sql修改的多行数据的变更记录，而canal、debezium等cdc组件会一次获取多行binlog到内部缓存，如果每行binlog都很大，会造成组件崩溃。

binlog_format

控制binlog内容，必须是ROW，这样binlog里才会包含具体发生变更的数据行，而不是用户提交的原始SQL。

binlog_row_image

控制binlog内容，必须是FULL，这样binlog里才会包含数据行变更前+变更后的全部信息。

kafka broker参数

https://docs.confluent.io/platform/current/installation/configuration/broker-configs.html

message.max.bytes

每个分区可接收的最大batch size；建议10485760

socket.request.max.bytes

producer一次提交的数据最大size，含多个分区的batch；建议104857600

fetch.max.bytes

consumer一次请求可获取的最大size，含多个分区的batch；建议104857600

kafka producer参数

https://docs.confluent.io/platform/current/installation/configuration/producer-configs.html

linger.ms

producer积累一段时间的消息后，再一次性批量发送给broker；建议1000

buffer.memory

默认够大，有100M，用于上述积累消息的过程

batch.size

可发送到一个分区的batch的最大值；与linger.ms条件满足其一，producer即进行一次实际的数据发送

max.request.size

发送到一个broker的数据大小限制，含多个分区的batch

kafka consumer参数

https://docs.confluent.io/platform/current/installation/configuration/consumer-configs.html

fetch.min.bytes

通知broker积累足够量的数据后，再一次性返回结果给consumer；建议20M

fetch.max.wait.ms

通知broker等待足够长的时间后，再一次性返回结果给consumer；与fetch.min.bytes条件满足其一，broker即返回结果给consunmer；默认值500，为避免clickhouse过快创建数据块，建议改为2000

reconnect.backoff.ms

与broker连接异常后，等待一段时间再进行重连；建议2000

reconnect.backoff.max.ms

每次重连的等待间隔都会增大，最长一次等待此参数时间还无法连接broker后，就不再进行重连；建议60000

max.poll.interval.ms

业务代码在此时间内没有调用poll方法申请消费下一批数据，则consumer客户端判断消费业务逻辑异常，自行停止心跳断开与broker的session