目录
集群架构
幂等性
生产者写入分区策略
消费者组再均衡
消费者规则
副本机制
低级api 高级 api
Kafka-eagl监控工具
分区的leader 与follower
Ar 、ISR 、 OSR 已分配副本 同步中副本 、不同步副本
Controller
执行leader 重新分配
分区=分布式
副本=备份和数据服务-副本一般大于1 可以容错
消费者指定分区
生产者指定分区
Offset = 偏移量 存在 zookeeper 中
可以自动提交offset 到 zookeeper
Offset 对应分区
桶 是服务器 生产者消费者链接桶
集群有多个桶注册实现负载均衡
主题多个，一个主题有多个分区
逻辑结构果审查消费都要指定topic
分区是分布式，topic 可以在多个分区中
消费组消费对应的topic配置group.id 一样消费者属于通一个组
Offset 偏移量，相对消费者，分片可以通过offset拉去数据
多个分区对应多个消费者
俩个消费者消费一个分区=一个等待一个消费
多少个分区，只能被同一个分组中多个少个消费者消费
幂等性
防止重复一模一样数据
如果一个任务生成失败，重试，多次可能出现幂等性问题一样值
Sequence Number （递增id）+PID 和生成这一起发送，kafka 检查,保存成功返回ack
Sequence Number （递增id）+PID实现生产者的防止幂等性
- 生产者 发送到分区，kafka 保存到分区，返回一个ack ,若果失败，生产者会重新发送
- Kafka开启幂等性
- Kafka 生成消息的时候会增加一个pid 生产者唯一编号，和sequencenumber 最大消息递增
- 发消息会练着pid和sequence number 一块发送
- Kafka 接受道下次，会将消息和pid sequence number 一并保存小赖
- 如果ack响应失败，生产者重试，再次发送消息，kafka会根据pid和 sequence number 是否保存同一条消息
- 判断条件，生产者发过来的sequencenumber 是否小于等于分片中的sequence
- 实现防止重复
生产者写入分区策略
- 轮询分区
- 随机分区
- 按照key分区
- 自定义策略
乱序问题
Key = null 默认 轮询 规则
消费者组再均衡
- 消费者数量发生变化，触发
- 订阅主题数量发生变化，触发
- 订阅分区数量发生变化，触发
触发，所有消费者暂停等待，重新分配规则执行（均衡消费者）
消费者规则
Range范围分配策略
8%3 3 3 2
RoundRobin 轮询
Stricky 粘性分配
发生再分配的时候尽量和之前一样
副本机制
数据丢失，依然保证数据可用
生产者Ack 规则：
- -1 or All 全部副本同步，再发一下一条，性能稍低一点，保证数据不丢失
- 0 不等待副本同步，性能最好会有概率数据丢失，性能高
- 1 成功写入领导分区，再发下一条（一个分区有一个领导），性能中
分区有 领导 和 随从 :
- 领导为了消费数据是一直的，只能从一个分区中读写消息
- Follower 事情做同步数据 backup
低级api 高级 api
- 低级api操作性更强
- 高级api操作内容少简单集成
Kafka-eagl监控工具
- KAFKA-eagle 监控集群可视化工具
EFAK
开启 kafka jmx 端口
分区的leader 与follower
- 每个分区都有一个leader实现均衡
- Follower 制作副本，leader挂掉的时候替补上去
Ar 、ISR 、 OSR 已分配副本 同步中副本 、不同步副本
- AR分区所有已分配副本
- ISR 在同步中的副本
- OSR 不同步副本
如果有一个节点挂掉，分区领导会渠道其他地方当上领导 保持分区总数到位
应为数据量大要保证性能所以尽快选举领导
如此设计副本作为及时选举当上领导实现高性能
举个例子
0、1、2 节点 三个 副本 0挂掉 0的领导会在 1 or 2 上马上出现领导，实现保证分区全在
Controller
每个桶中有一个 controller 执行api
- 每个节点启动都会去zk 上申请成为 controller
- 如果有一个节点挂掉 会再次申请 controller