kafka详解

kafka：消息/存储/流处理

partition:offset(每message占1),分区内有序，分区数可考虑为 broker 的倍数
segment：baseOffset+file+offset index(relative offset-position)+timestamp index(timestamp - relative offset,注意后面到来的message如果timestamp更小则不入timestamp index)
offset查找message：找segment（skiplist),找offset index(二分，其实我觉得可以算出在offset index的位置)
timestamp查找message:找segment(每个segment的最大timestamp比较)，找timestamp index(二分),找offset index(二分)

日志清理：log.cleanup.policy，默认delete，compact指同key的message保留最后一条
删除segment即delete:
1 时间：segment存在过长，默认7天
2 大小：segment超长
3 offset: segment内所有message的offset小于某值

删除topic:
delete命令/zk创建节点/删除数据和zk上的metadata

replica可增减，partition可增不可减(减那么partition数据怎么办，放其它partition那么数据乱序，数据乱timestamp，且迁移过程可用性怎么办)
replica:leader读写 follower拉取leader进行同步
preferred replica：AR的第一个，尽量保证preferred replica被选为leader(分区平衡,即定期重新选leader往preferred上靠，auto.leader.rebalance.enable,默认true),kafka会通过preferred replica均衡分布来保证leader均衡
分区重分配:增减broker，replica迁移

ISR:in-sync，时间控制(follower滞后leader时间超过阀值)，AR=ISR+OSR
hw(high watermark):partition所有replica共享，代表consumer可消费的位置+1(即ISR内最小leo)
leo:每个replica都有，代表当前replica的写入位置+1
follower带leo请求leader，leader根据各follower的leo计算hw，返回message和hw给follower
数据一致性：如何保证老Leader 还是新选举的 Leader，Consumer 都能读到一样的数据？
基本所有副本都是ISR，但是ISR内Leader依然稍稍领先follower，如果直接读Leader最新消息那么Leader挂了在新Leader上却无法读取到此消息，不一致，所以只能读到hw

producer:producer interceptors - serializer - partitioner - record accumulator(每个partition多batch), sender thread发送
发后即忘/同步发送(future等待)/callback

consumer:poll拉取
subscribe 订阅topic (集合或正则)
assign 订阅partition (集合)
unsubscribe/subscribe(空)/assign(空) 取消订阅

__consumer_offsets: 此topic记录offset提交情况 committed offset=lastConsumedOffset+1,offset提交理解为ack
常见问题：重复消费(提交晚了)/数据丢失(提交早了)
自动提交：默认自动，enable.auto.commit
手动：commitSync/commitAsync

auto.offset.reset:consumer找不到offset怎么拉取？默认latest(分区尾部),earliest(分区起始),none(不消费)
seek:可在自己消费的partition上指定offset消费(重置offset)，需先poll分配分区
再均衡:consumer增减导致partition的所有权变更,尽量避免(期间consumerGroup不可用，组内所有consumer不可读消息)

producer分区：
1 发送时指定partition
2 partitioner：DefaultPartitioner(存在key按key hash所有partition，否则轮询所有可用partition)，也可自定义partitioner
consumer分区：partition.assignment.strategy 指定Assigner
同一group下各consumer订阅的topic列表可不同，找到group订阅的所有topic，对每一个topic，如何分配到订阅它的各consumer？
1 默认RangeAssigner: consumer均分所有分区(由于余数前面的consumer每个多分一个)，c0:p0,p1,c1:p2，consumer分配到一个partition range
2 RoundRobinAssigner：各consumer订阅topic相同，所有topic的所有partition一起轮询，否则按单个topic的partition轮询分配，c0:p0,p2,c1:p1
3 StickyAssigner：尽量均匀且consumer下线重新分配尽量保证和以前一致
broker 分区副本分配
创建topic时replica-assignment指定，否则默认(1未指定机架信息，需所有broker未配置broker.rack或创建topic时disable-rack-aware 2指定机架信息 )

bootstrap.servers:指定broker集群的机器，最好2台以上，一台不行还有备用，客户端只是想先连上broker集群的任一机器
key(value).serializer/deserializer: producer和consumer需对应
group.id：consumer用来指定consumerGroup
acks：多少replica收到message才成功，-1(all)需ISR全部同步完才返回客户端应答(同步复制)，1指leader写入即可(异步复制)，0指发出即可不等响应

顺序性：partition写入有序，单partition只能被单个消费者消费
高性能/高吞吐
1 顺序写:不断append
2 page cache:file的inode含文件系统block列表，file的page cache含page的radix树结构,两者对应
所有read都过page cache(读不到缺页异常进行磁盘加载)，所有write都写入page cache，手动fsync/周期fsync/操作系统自行fsync-自己决定
3 zero copy: 减少上下文切换和数据复制，linux底层通过sendfile，java中可以通过FileChannel.transferTo
非zero copy:disk-read buffer-app-socket buffer-nic buffer(网卡) 4次复制，4次上下文切换
zero copy:disk-read buffer-nic buffer(网卡) 2次复制，2次上下文切换
底层数据复制DMA(direct memory access)可完成，无需cpu：disk-read buffer， read/socket buffer-nic buffer
上层数据复制需cpu:read buffer-app,app-socket buffer
4 消息压缩/批量发送/分区分段+索引文件

幂等+事务实现exactly once
幂等: enable.idempotence,producer按照<producerId,partition>给message加seq number, partition收到某producer重复的seq丢弃，收到过大的seq则发生乱序，中间有message丢失
事务: 需开启幂等，保证多分区写入的原子性，幂等的增强(跨生产者会话),但不能保证committed transaction的所有消息都能被消费到

可靠性
多副本/acks=-1配合min.insync.replicas，若ISR只有leader，那么acks=-1即acks=1，需保证ISR的最小数量/手动提交/seek兜底