kafka
2021-12-15 20:53:27 2 举报AI智能生成
kafka 入门级
作者其他创作
大纲/内容
log.dir
指定broker需要若干个文件目录，需要手动配置，无默认
在kafka1.1前，如果一个磁盘失败了，kafka挂掉
kafka1.1后，坏掉的磁盘会自动把数据传输到好的磁盘上
提高读写效率
好处
建议不同目录设置到不同物理磁盘上
链接zookeper，可逗号隔开
zookeper.connect
log.dirs
broker
自动新建topic，默认开启，建议关闭
auto.create.topics.enable
unclean.leader.elecction.enable
定期选举leader，建议设置false，本来是读写在A，选举读写B去了，本质上没什么性能增益
auto.leader.rebalance.enable
默认1周，删除策略
设置topic在brokder的保存时长
可以在创建topic的设置默认时间
retention.ms
设置大小，规定topic在broker预留多少磁盘空间
-1，无限
retention.byte
topic
消息在broker存储的时间
不设置，默认是168h
log.retention.house/minutes/ms
保存消息broker总预留的磁盘空间
默认-1，无限
log.retention.bytes
存储
基础设置
0:生产者往broker推送消息，推送过去，不需要等待broker回应；好处：效率高 坏处：安全性低，因为不知道是不是发送成了
1:生产者推送消息，leader回应是否成功；不需要管是否副本同步成功；
all:生产者发送消息，确保leader和follower都成功。
ack
索引
批量读写
传统io，磁盘文件拷贝到内核缓冲区，在内核缓冲区拷贝到用户缓冲区；在返回的网卡
DMA函数：直接是磁盘文件靠谱到内核缓冲区；在内核缓冲区拷贝到网卡，省略了用户缓冲区（cpu）拷贝
零拷贝DMA
kafka为何高效
生产者发送消息到broker的一个别名，消费者通过topic来订阅生产者生产的数据
数据量过多，一个topic目录下文件过大，所以这里引入分区。在多个broker下设置多个分区，类似分库分表的概念。
解决横向扩展
12323 --> 23242343222232 --> 453453455
索引是一个段，默认是4Kb，分一个段索引
默认10M，如果超过10M，那么就会生出一个新的segment
索引文件
追加消息
log文件
段时间戳索引
时间戳索引
为了解决文件过大，导致读写慢，且文件丢失，全部没了
partition目录文件
删除(默认)：默认1周会删除，可设置小时/分钟；也可以设置文件大小后删除
压紧:一个topic同一个key保存一个最终消息
文件删除策略log.cleaner.enable:true -默认为truelog.cleanup.policy = delete/compact
副本分布策略：先确认leader位置，在蛇形走位，确认副本节点
防止数据丢失
副本数量小于broker数量
leader节点才能为客户端提供读写，这样做的目的，是为了数据读写一致性
副本机制
partition
当log文件过大时，检索就慢了，就容易出事，所以需要分段
新建segment是一套的，会新建3个文件
segment
作用：消费者组不同的消息者，是为了同一个topic不同的分区，消费者组的一个消费者只能消费一个分区
消费者组里面的消费者数量 > 分区，那么消费者里面的消费者存在闲置情况
随机
轮训
范围
粘滞
消费分配方式partition.assignment.strategy
consume group
GroupMetadata:保存了消费者组中各个消费者的消息
group_id
topic_partition
offset
offsetAndMetadata：保存了消费者组合各个partition的offset位移信息
特殊的topic/默认50个
通过生产配置属性：group_id.hashCode() % 50，也存入消费者读写了分区的偏移量
消费者消费topic；分区读取的偏移量
latest:从最后读
earliest:从头开始读
none:未找到偏移量，报错
auto.offset.reset
新增消费者
默认自动提交
消费后，手动同步提交
消费后，手动异步提交
consumer
术语
可以批量发送消息
推送消息
kafka只有poll，没有push因为kafka处理数量大，如果生产者远远大于消费者的时候，会给消费者带来很重的负担
批量poll，可配置，默认500
消费消息
发送/消费
副本机制：术语中已描述
如果副本节点过多，在zookeper生出临时节点过多，大量的watch
还可能导致脑裂
早期使用zookeper使用做选举功能
1、选举出一个broker，在zookeper写入，谁先写入，谁就是主持人
ai：所以参与broker副本
isr：跟leader保持同步的副本，如果都没有跟leader保持同步，会从osr中选举
osr：被踢出去的副本（延迟30ms，就会踢出去）;如果主从同步了，延迟小于30ms，又会丢进到isrunclean.leader.elecction.enable=true，osr参与，默认是false
2、把所以broker全部选出来
副本编号更小优选称为leader
可参考副本机制描述，蛇形作为
假设选举的leader是hw是6的，那么消费的数据只能消费到6，kafka任务7-9消息不可靠所以7-9的被截至了，数据丢失了。如果是选举为9的，那是良好的情况，会把最新的发送到其他副本.
每个副本的下一条等待写入的offset
LEO
HW
使用PacifcA优选算法
3、确定哪些可以参与的broker
保证数据一致性，不能保持数据可靠的存储
新版选举方式
其他副本超过leader-hw的offset截至掉
其他副本小于leader-hw，其他发起fowe先从，同步leader的数据
当前leader的hw
根据副本编号小的当leader
leader宕机
leader
蛇形走位
follower副本存放策略
宕机一致起不来，则剔除节点
宕机后，一会儿又起来了：向leader发起询问leader的hw，需要同步到那个offset的数据
follower宕机
follower
集群
kafka
0 条评论
回复 删除
下一页
