目录
kafka架构简述
kafka高性能高吞吐的原因
kafka副本同步机制
Kafka消息高可靠解决方案
简述kafka的rebalance机制
kafka架构简述
Consumer Group:消费者组，消费者组内每个消费者负责消费不同分区的数据，提高消费能力。逻辑上的一个订阅者。
Toplc:可以理解为-个队列，Topic 将消息分类，生产者和消费者面向的是同一个Topic。
Partition:为了实现打展性，提高并发能力，一个Topic以多个Partition的方式分布到多个Broker.上,每个Partition是一个有序的队列。一个Topic的每个Partition都有若干个副本(Replica) ，一个Leader和若干个Follower。生产者发送数据的对象，以及消费者消费数据的对象，都是Leader. Follower负责实时从 Leader中 同步数据，保持和Leader数据的同步。Leader 发生故障时，某个Follower还会成为新的Leader.
kafka高性能高吞吐的原因
1、磁盘顺序读写:保证了消息的堆积（数量肯定大于内存消息堆积的很多倍）
- 顺序读写减少了传统随机读取磁盘磁头转动等产生的耗能，磁盘会预读，预读即在读取的起始地址连续读取多个页面,主要时间花费在了传输时间，而这个时间两种读写可以认为是一的。
- 随机读写，因为数据没有在一起，将预读浪费掉了。需要多次寻道和旋转延迟。而这个时间可能是传输时间的许多倍。
2、零拷贝:避免CPU将数据从一块存储拷贝到另外一块存储的技术
●传统的数据复制:
- 读取磁盘文件数据到内核缓冲区
- 将内核缓冲区的数据copy到用户缓冲区
- 将用户缓冲区的数据copy到socket的发送缓冲区
- 将socket发送缓冲区 中的数据发送到网卡、进行传输
●零拷贝: 磁盘文件->内核空间读取缓冲区->网卡接口->消费者进程 无CPU切换
3、分区分段+索引
Kafka的mesage消息实际上是分布式存储在一个个小的segment中的，每次文件操作也是直接操作的segment。为了进一步的查询优化， Kafka又默认为分段后的数据文件建立了索引文件，就是文件系统上的.index 文件。这种分区分段+索引的设计，不仅提升了数据读取的效率,同时也提高了数据操作的并行度
4、批量压缩:多条消息-起压缩，降低带宽
5、批量读写
6、直接操作page cache,而不是JVM、避免GC耗时及对象创建耗时，且读写速度更高，进程重启、缓存也不会丢失 。读写也都从page cache中
kafka副本同步机制
LEO:下一条待写入位置
firstUnstableOffset:第一条未提交数据
LastStableOffset:最后-条已提交数据
LogStartOffset:起始位置
isolation.level=read_ committed:只能消费到LastStableOffset, read. committed可以消费到HW的上一条
一个partition对应的ISR中 最小的LEO作为分区的HW, consumer 最多只能消费到HW所在的位置 leader收消息后会更新本地的LEO, leader还会维护follower的LEO即remote LEO, follower发出fetch同步数据请求时(携带自身的LEO)、leader会更新remote LEO,更新分区的HW,然后将数据响应给ollower. follower更新自身HW(取响应中的HW和自身的LEO中的较小值)，LEO+1
ISR:如果一个follower落后leader不超过某个时间阈值，那么则则ISR中， 否则将放在OSR中（Out 不在SR中）。
同步副本时，follower获取leader的LEO和LogStartOffset, 与本地对比、如果本地的LogStartOffset超出了leader的值，则超过这个值的数据删除，再进行同步，如果本地的小于leader的、则直接同步
Kafka消息高可靠解决方案
消息发送:
- ack: 0、不重试，1. leader写入成功就返回了，all/-1. 等待ISR同步完再返回 所有follower同步完才返回
- unclean.leader .election.enable : false, 禁止选举ISR以外的follower为leader
- tries> 1,重试次数
- min.insync.replicas> 1:最小同步副本数,没满足该值前、不提供读写服务、写操作会异常
消费: 手工提交offset确保消息消费掉了
broker:减小刷盘间隔减少消息丢失概率
事务消息
简述kafka的rebalance机制
consumer group中的消费者与topic下的partion重新匹配的过程 平衡消费者和partition
何时会产生rebalance:
- consumer group中的成员个数发生变化
- consumer消费超时
- group订阅的topic个数发生变化
- group订阅的topic的分区数发生变化
coordinator协调者:通常是partition的leader节点所在的broker,负责监控group中consumer的存活，consumer维持到coordinator的心跳，判断consumer的消费超时
- coordinator通过心跳返回通知consumer进行rebalance
- consumer请求coordinator加入组， coordinator 选举产生leader consumer
- leader consurmer从coordinator获取所有的consumer ,发送syncGroup(分配信息)给到coordinator
- coordinator通过心跳机制将syncGroup下发给consumer consumer就知道要去消费哪个partition了
- 完成rebalance
leader consumer监控topic的变化。通知coordinator触发rebalance
如果C1消费消息超时并没有提交offset，触发rebalance, 重新分配后、该消息会被其他消费者消费提交offset，此时C1消费完成提交ffset导致错误 同一条消息提交了两次offset
解决: coordinator每次rebalance, 会标记一个Generation给到consumer, 每次rebalance该Generation会+1, consumer提交offset时, coordinator会比对Generation, 不一致则拒绝提交
