最近在鹅厂工作中不断接触到Kafka，虽然以前也使用过，但是对其架构和发展过程总是模模糊糊，所以在回学校准备末考的时候找些资料总结一下。 Kafka Need No Keeper 是一个在Kafka Submit分享的标题，我也是看了Kafka needs no Keeper（关于KIP-500的讨论）这篇博客分享后才对Kafka有了初期的认识，如果想要了解细节的话可以直接阅读该博客分享，本篇博客是一次对Kafka的自我总结，多少有些大白话和概括之意。

Kafka是什么？Apache Kafka 是一款分布式流处理框架（新版本后，定位发生了改变），用于实时构建流处理应用。 Kafka的架构可以简单分为Client和Broker两部分。在Kafka发展过程中，Kafka都是不断减少这两部分对Zookeeper的依赖。 那为什么要减少对Zookeeper的依赖呢？

Client一般分为三类，Consumer Client、Producer Client和Admin Tool。

可以看出，Zookeeper在Kafka中①存储元数据

新版主要针对旧版中的Consumer Client和Admin Tool改进

在现阶段结构中，Broker端是严重依赖Zookeeper的，基本上所有元数据信息和管理都要通过Zookeeper集群，如下图：

可以看出，Zookeeper在Kafka中有②集群管理和③选举Controller的作用

第一步首先是隔离非Controller端对ZK的依赖； 第二步是移除Controller端对ZK的依赖，这一步可以采用基于Raft的共识算法来做(?)。

ISR中的Leader是由Controller指定，与Leader保持同步用指标来衡量就是follower中Leo落后leader中Leo的时间不超过指定时间范围（replica.lag.time.max.ms=10s）。 （在旧版本中还有另外一个指标是落后的Leo条数，不过这样子的话每次发送大量数据后，一开始ISR就只有leader，到后面follower跟上的才能加入ISR，这样子会导致ZK的频繁写入修改性能下降）

另外在Leader挂掉后，Controller会让ISR中的一个Follower成为Leader，并且开始同步新的Leader的Offset。这里要注意的是有可能此时ISR中并没有Follower，所以有两种选择，①允许OSR的Follower成为Leader和②该分区没有Leader。这来源于设置unclean.leader.election.enable，设置为true为选择①，保证了系统的高可用性和损失了一致性，设置为false为选择②，保证系统的一致性和损失高可用性。

同时一个Leader和多个Follower看上是读写分离的结构，但是Kafka并不支持读写分离。原因由两点，①场景不合适，读写分离适用于读负载很大，而写操作不频繁的场景，显然Kafka不是；②同步机制，Follower和Leader之间存在不一致的窗口，很可能出现消息滞后（类似于幻读）

这主要决定了Producer发送信息时，Kafka的接受机制，有三种：

那么问题就来，怎么实现Exactly Once呢？

这里讨论的Exactly Once主要是针对Producer端，至于消费者的Exactly Once可以在客户端上保留偏移量来实现（参见flink事务机制）。

先来讨论单Session的情况，在Kafka中给每个Producer都分配了一个内部的唯一的PID，每次Producer发送信息时，带有的主键是，Leader端收到信息后对相同的的Sequencenumber进行比较，如果来的信息比Leader端的小，证明数据重复，丢弃该条信息；如果来的信息比Leader端的大1，插入该信息；吐过来的信息比Leader端的大超过1，证明发生了乱序丢弃该信息。

具体内容参考这篇博客

在单Session的情况如果存在PID都可以保证Exactly Once，那么要是在不同的Session中我能拿到相同的PID就可以了。所以引入了一个TID（自己定义的）并且绑定了事务一开始的PID，只要事务没有提交，那么每次都拿着这个TID去获取对应的PID就可以保证Exactly Once了。

内部引入了一个transaction Coordinator用于分配PID和管理事务，并且在内置了一个主题transaction Log用于记录事务信息，事务的操作简图如下：

以上是大佬教程为你收集整理的Kafka 总结学习全部内容，希望文章能够帮你解决Kafka 总结学习所遇到的程序开发问题。

如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。