CDC事件处理流程图mysql参数
binlog-row-event-max-sizebinlog_formatbinlog_row_image kafka broker参数
message.max.bytessocket.request.max.bytesfetch.max.bytes kafka producer参数
linger.msbuffer.memorybatch.sizemax.request.size kafka consumer参数
fetch.min.bytesfetch.max.wait.msreconnect.backoff.msreconnect.backoff.max.msmax.poll.interval.ms
本文针对海量binlog事件处理场景，列出让事件流能够高效处理的关键参数
下图描绘了使用canal或者flink cdc，采集binlog并处理、保存到clickhouse的过程；
建议从slave节点采集binlog，避免增大master传输压力
mariadb只能在启动文件里配置此参数，用于控制一行binlog的大小，建议不大于1M。
一行binlog可能包含一条sql修改的多行数据的变更记录，而canal、debezium等cdc组件会一次获取多行binlog到内部缓存，如果每行binlog都很大，会造成组件崩溃。
控制binlog内容，必须是ROW，这样binlog里才会包含具体发生变更的数据行，而不是用户提交的原始SQL。
binlog_row_image控制binlog内容，必须是FULL，这样binlog里才会包含数据行变更前+变更后的全部信息。
kafka broker参数 message.max.bytes每个分区可接收的最大batch size；建议10485760
socket.request.max.bytesproducer一次提交的数据最大size，含多个分区的batch；建议104857600
fetch.max.bytesconsumer一次请求可获取的最大size，含多个分区的batch；建议104857600
kafka producer参数 linger.msproducer积累一段时间的消息后，再一次性批量发送给broker；建议1000
buffer.memory默认够大，有100M，用于上述积累消息的过程
batch.size可发送到一个分区的batch的最大值；与linger.ms条件满足其一，producer即进行一次实际的数据发送
max.request.size发送到一个broker的数据大小限制，含多个分区的batch
kafka consumer参数 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
