Kafka复习
2021-04-10 19:46:47 0 举报AI智能生成
kafka知识点总结
作者其他创作
大纲/内容
producer
发送流程
1、用户线程封装消息到ProducerRecord
2、发送给partitioner确定目标分区，放入内存缓冲区
3、Sender线程从缓冲区中取出就绪消息封装成批次统一发送给对应的broker
发送方式
同步发送
异步发送+回调
异常
可重试异常
LeaderNotAvailableException
NotControllerException
NetworkException
不可重试异常
RecordTooLargeException
SerializationException
分区策略
根据key的hash值来选择目标分区
未指定分区时，采用轮训的方式分配
自定义分区策略
常见参数
acks
acks=0
acks=all或者-1
acks=1
buffer.memory
compression.type
retries
retry.backoff.ms
batch.size
linger.ms
max.request.size
request.timeout.ms
拦截器
onSend
onAcknowledgement
无消息丢失配置
producer端
max.block.ms=true
acks=all
retries=Integer.MAX_VALUE
max.in.flight.request.per.connection=1
broker端
unclean.leader.election.enable=false
replication.factory>=3
min.insync.replicas>1
replication.factory>min.insync.replicas
精准一次语义
幂等
事务
consumer
consumer分类
独立消费者
消费者组
一个消费者组有多个消费者实例
对于同一个group，topic的每条消息只能被发送到该group下的一个消费者实例
同一个topic消息可以被发送到多个group中
消息顺序性
位移（offset）
consumer group保存offset
位移提交
自动提交，默认5秒一次
手动提交
__consumer_offsets
分为50个offset文件目录
一个日志文件
.log
group.id+topic+partition:offset
两个索引文件
.index
.timeindex
定期压缩日志文件
消息交付语义
最多一次
最少一次（默认）
精准一次
其他位置信息
上次提交位移
当前位置
水位
日志终端位移
获取消息
常见参数
session.timeout.ms
max.poll.interval.ms
enable.auto.commit
fetch.max.bytes
max.poll.records
heartbeat.interval.ms
connections.max.idle.ms
rebalance
触发条件
1、组成员发生变更
新成员加入
成员崩溃
主动离场
2、组订阅topic发生变更
3、订阅topic的分区发生变更
分配策略：consumer进行分配
range
round-robin
sticky
generation
rebalance流程
确定coordinate，和提交topic确定partition一样，groupID的hashcode取模50，对应partition所在broker
加入组：所有组内consumer向coordinate发送加入请求，分配策略不兼容则剔除
coordinate转发所有成员信息给consumer leader
consumer leader定制分配方案，然后发送给coordinate
coordinate将每个consumer的分配方案抽取出来发给对应consumer
kafka为什么搞吞吐低延迟
大量使用操作系统的页缓存，内存操作速度快且命中率高
采用追加写入方式，顺序写入
零拷贝技术
kafka消息采用紧凑的字节数组保存
将消息仅写到页缓存中，之后由操作系统将页缓存中的消息刷到磁盘
常见概念
topic
partition
offset
replica
leader replica
follower replica
ISR
新旧版本变化
producer
1、发送过程由两个线程处理，用户线程将封装好的消息扔到缓冲区，Sender I/O线程将缓冲区消息分批次发给broker
2、异步发送，提供回调机制判断发送成功与否
3、分批机制，每个批次包括多个发送请求
4、更合理的分区策略，对于没有指定key的消息，采用轮训分区的方式分配，以免造成数据倾斜
consumer
1、旧版的消费位移依赖zookeeper管理，新版本的位移放在kafka的一个内部topic中
2、使用类似epoll的机制，一个线程管理连接多个broker的socket连接
3、消费者组的成员管理由zookeeper变成了coordinator
线上环境部署
磁盘容量规划
消息数
平均消息大小
消息留存时间
副本数
是否启用压缩
内存规划
尽量分配更多的内存给操作系统的页缓存
不要为broker设置过大的堆内存，最好不超过6GB
页缓存大小至少大于一个日志段的大小
带宽规划
多节点zookeeper
broker参数
unclean.leader.election.enable
log.retention
min.insync.replicas
num.network.threads
num.io.threads
message.max.bytes
JVM
CPU充足，要求低延迟：CMS
吞吐量优先：并行
jdk8：G1
系统参数
文件描述符：设置一个大值100000
Socket缓冲：64KB，跨区128KB
页缓存刷盘默认5秒，建议2分
各种选举
controller选举
分区leader选举
coordinate选举
consumer leader选举
broker
成员管理
ISR
位移信息
高水位值HW
日志终端位移LEO
follower与leader不同步原因
follower请求leader同步的速度小于leader接收消息的速度
follower进程卡住，例如FullGC
新创建的副本
不同步的标准
LEO更新机制
1、leader副本写入日志，leader LEO变为1
2、follower副本fetch请求leader，follower副本LEO=1
3、第二次fetch，remote LEO=1，HW=min(leader LEO,remote LEO)=1
4、follower HW=min(follower LEO,leader HW)=1
没有leader epoch时的缺陷
数据丢失：leader HW未全部同步到follower就挂了
数据不一致：leader HW未全部同步到follower就挂了，follower立即写入消息和重启后的leader HW一直
leader epoch
解决消息丢失
解决消息不一致
日志存储
日志段文件
日志索引文件
位移索引文件
相对位移
物理位移
时间戳索引文件
时间戳
相对位移
日志存留
基于时间的存留策略
基于大小的存留策略
日志压缩
controller
选举
1、先在zookeeper创建Controller节点成功的获选
2、其他节点监听zookeeper上的Controller节点
3、一旦Controller崩溃其他节点都会收到消息，再次开始竞选
controller职责
更新集群元数据到其他broker
zookeeper上面新建topic对应节点，Controller监听后为topic分区确定leader和ISR再广播出去
broker处理请求
一个acceptor线程监听连接，分配给processor
多个processor线程（默认3个）处理所分配的连接的IO操作，交给线程池任务队列
实际业务处理线程从池获取任务进行处理，默认8个
0 条评论
下一页
