kafka图谱

heartbeat.interval.ms: 多久发送一次心跳

session.timeout.ms: 
broker多久没有收到该消费者的心跳就会被认为是断线的 ,
该值一定要比 "heartbeat.interval.ms" 大

max.poll.interval.ms:
多久没有去broker拉取消息就会被认定为断线的 .
 max.poll.interval.ms与session.timeout.ms 关系: 消费后台有两个线程, 一个是进行心跳检测的,
另一个是进行数据处理的, 数据处理多长时间都不会影响心跳检测. 即如果消息需要处理很长时间,
broker可以通过心跳检测更快的检测到消费者掉线的情况 .

fetch.min.bytes: 一次最多拉去多少字节的数据

fetch.max.wait.ms: 拉取数据时最多等待多长时间, 超过该时间即使没有拉取到数据也会返回

max.poll.records: 一次最多拉去多少条记录

enable.auto.commit : 是否自动提交

auto.offset.reset: 从哪里开始消费

提交offset

再均衡

所有消费者的offset都会存在 krober的 _consumer_group 的topic中 , 存储时间默认为一天

消费者只有在初始化的时候会查询 _consumer_group 中的offset, 之后使用自己保存的offset

以消费者组为最小单位进行消费,  即一条消息在一个消费者组内只会被消费一次, 在不同消费者组内可能会被消费多次

retries: 
acks: 需要配合:  min.insync.replicas<在topic配置>使用

buffer.memory:  如果往broker发送数据很慢 ,但是producer写入数据又很快 ,数据就会被先缓存到该内存
batch.size: producer需要为每个分区预留的内存大小 . 当batch.size 满了 , 才会发送消息
max.in.flight.requests.per.connection: 阻塞之前单个连接可以发送的未应答请求的最大数 , 一个producer 可以保证单个partion的顺序性
linger.ms: 消息发送延迟时间, 即等待消息多一些一起发送.

生产者会先把消息缓存下来, 每个分区都有自己的缓存区,
当缓存区满了之后一起发送,或者是等时间到了也会发送

生产者会根据key进行hash,把消息放入不同的分区, 如果没有key就轮询

主要负责partition管理和副本管理

ISR: 消息跟上了leader副本会被放在这列表,当leader宕机后controller用第一个副本作为新的leader
OSR: 消息落后了的副本会被放在这个列表
LEO: 每个副本都有一个LEO, 即副本最后一个消息的offset+1
HW:  某个分片所有副本中最小的LEO

replica.lag.max.messages: 副本最多可以落后leader多少个消息
replica.lag.time.max.ms: 过了多长时间副本没有同步leader的消息会被认定为 "没有跟上leader的消息"

follow 会定时去leader处拉取消息, 和consumer差不多

负责controller的选举

检测broker是否宕机

每个topic都可以有多个分区, 默认为五个 . 

设计时, 需要根据生产者的生产能力及消费者消费速率设置分区数量

分区可以增加, 但是无法保证相同的key会写入相同的分区

可以为每个分区设置多个副本, controller 会维护一个分区副本列表,
如果分区leader宕机, 使用列表第一个作为新的leader

如果掉线的leader重新连接, 在同步完数据后会重新成为leader, 为了节点的负载均衡

controller维护一个ISR列表,当分区leader宕机后, ISR列表的第一个节点副本成为新的leader

节点的数据不能落后leader太多 否则不能当选