ack
0:生产者往broker推送消息，推送过去，不需要等待broker回应；<br>好处：效率高 坏处：安全性低，因为不知道是不是发送成了
1:生产者推送消息，leader回应是否成功；不需要管是否副本同步成功；
all:生产者发送消息，确保leader和follower都成功。
kafka为何高效
顺序读写-寻址快.log文件不删除时,读写入追加
索引
批量读写
零拷贝DMA
传统io，磁盘文件拷贝到内核缓冲区，在内核缓冲区拷贝到用户缓冲区；在返回的网卡
DMA函数：直接是磁盘文件靠谱到内核缓冲区；在内核缓冲区拷贝到网卡，省略了用户缓冲区（cpu）拷贝
术语
broker
kafka节点都有broker, 生产者与消费者关联
topic
生产者发送消息到broker的一个别名，消费者通过topic来订阅生产者生产的数据
如果未定义，broker自动创建topic，可关闭,一般建议关闭
partition<br>
数据量过多，一个topic目录下文件过大，所以这里引入分区。在多个broker下设置多个分区，类似分库分表的概念。
解决横向扩展
partition目录文件
索引文件
段索引,所以查索引二分查找
12323 --> 232423432<br>22232 --> 453453455
检索索引：文件名已经包含了offset偏移量，找到对应的segment,找到找到log
索引是一个段，默认是4Kb，分一个段索引
默认10M，如果超过10M，那么就会生出一个新的segment
为了解决文件过大，导致读写慢，且文件丢失，全部没了
文件删除策略<br>log.cleaner.enable:true -默认为true<br>log.cleanup.policy = delete/compact
删除(默认)：默认1周会删除，可设置小时/分钟；也可以设置文件大小后删除
压紧:一个topic同一个key保存一个最终消息
副本机制
副本分布策略：先确认leader位置，在蛇形走位，确认副本节点
防止数据丢失
副本数量小于broker数量
leader节点才能为客户端提供读写，这样做的目的，是为了数据读写一致性
follower,只有备份功能
segment
当log文件过大时，检索就慢了，就容易出事，所以需要分段
默认log文件大于1G的时候, 就create一套新的index/log等，文件名，是通过上一个偏移量文件
新建segment是一套的，会新建3个文件
consume group
作用：消费者组不同的消息者，是为了同一个topic不同的分区，消费者组的一个消费者只能消费一个分区
消费者组里面的消费者数量 > 分区，那么消费者里面的消费者存在闲置情况
消费者组里面的消费者数量 < 分区, 可能一个消费者消费多个partition
消费分配方式<br>partition.assignment.strategy
随机
轮训
范围
粘滞
consumer
消费者消费topic；分区读取的偏移量
特殊的topic/默认50个
GroupMetadata:保存了消费者组中各个消费者的消息
offsetAndMetadata：保存了消费者组合各个partition的offset位移信息
group_id
topic_partition
offset
通过生产配置属性：group_id.hashCode() % 50，也存入消费者读写了分区的偏移量
新增消费者
auto.offset.reset
latest:从最后读
earliest:从头开始读
none:未找到偏移量，报错
消费完，提交到broker，告知消费完成<br>enable.auto.commit,偏移量才更新
默认自动提交
消费后，手动同步提交
消费后，手动异步提交
发送/消费
推送消息
可以批量发送消息
默认15384条，一批且不超过5秒,超过5秒立即发送
消费消息
kafka只有poll，没有push<br>因为kafka处理数量大，如果生产者远远大于消费者的时候，会给消费者带来很重的负担
批量poll，可配置，默认500
