携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第2天，点击查看活动详情
Broker
副本
- 副本的好处 -> 提高可靠性
- 生产环境通常两个 默认一个
- 有leader follower区分 生产者消费者针对leader
- ISR 存储正常通信的副本 30s 请求应答 超市剔除
- 副本选举机制 controller（zk中注册） 规则 在ISR列表存活 AR中排在前列的优先选举
- leader挂了 follower挂了
- LEO 最后offset+1 HW 水位线
- 副本分配 错位 保证数据安全可靠
- 手动副本分配 制定计划 执行计划 验证计划
- leader partition的负载均衡 10% -> 触发自平衡
- 手动增加副本因子
存储机制
broker topic partition log segment(1G) ->(.log 存储数据 .index 稀疏索引 4kb-1时间戳 快照)
删除数据
- 默认7天 保存三天 7h
- 删除策略
- 删除
- 一个segment数据全部过期 直接删除
- 有过期有未过期 等全部过期删除
- 压缩
- 按照每个key最新的value进行保存
- gzip等
- 删除
高效读写
- 分布式集群 分区技术
- 提高生产者 消费端并行的生产消费能力
- 处理海量数据 分治存储
- 稀疏索引
- 顺序读写 追加写
- 零拷贝 页缓存->linux内核缓存 数据直接放到linux缓存 选择硬盘和网卡 不走应用层（主要原因 在集群端只存储数据 不修改数据 ）
消费者
总体流程
消费者组
- 单个消费者也算消费者组
- 按照主题消费
- 配置
- 连接地址
- 反序列化
- 组id
- 创建消费者
- 订阅主题
- 消费数据 while循环 指定时间拉取
- 配置
- 按照分区消费
- 消费者组 -> group.id 相同即为一个消费者组
- 分区分配策略 再平衡
- Range 012 34 56 分区数求模 低分区多放 在topic多的时候会导致数据倾斜
- Roundrobin 轮询策略 036 14 25
- 粘性
- offset
- 默认存储在系统主题
- 自动提交 5s
- 手动提交 同步 异步
- 指定位置消费 seek
- 漏消费 重复消费（offset 和 提交的顺序不同）->解决方式 事务
- 事务
- 生产端-> 集群
- 集群->消费者
- 消费者->框架
- 数据积压
- 增加分区 增加消费者个数 性能
- 在生产端 ->Broker集群 修改参数 进行性能调优
- 消费端 50m 500条数据 修改参数
