今天详细介绍Kafka的体系结构和实现原理。 从“醉薰牛排”体系结构和细节入手，用生动的图详细说明Kafka的实现原理。
我想很多学生以前读过很多关于Kafka原理的文章，很多时候，“赶牛”的声音紧随其后，热情洋溢，感觉自己又学到了各种“吊天”的技术。 但是，很多同学认为，把文章结合面试问题背诵，也能应付半吊子的面试官。 可以会见老司机的面试官，也可以参加实战，但对很多概念和实现都很模糊。
所以，虽然决定对Kakfa进行图解，但很多不懂的学生可以加深对Kafka实现原理的理解。
另外，建议读者结合Kafka的构成来理解Kafka的实现原理。 Kafka有大量的配置，这也是Kafka高级扩展的一种表现，很多学生不能轻易改变Kafka的配置。 因此，通过了解这些配置背后的实现原理，您可以在实践中了解如何使用和优化Kafka。 你可以在面试中制造火箭，也可以在实战中制造火箭。
Kafka配置说明链接： https://Kafka.Apache.org/documentation
本文的主要内容如下。
由于内容太多，步伐太大，怕把鸡蛋扯掉，[醉熏牛排]决定把文章分成三部分。 本文只讨论了上图中的“橙色”部分。
在本文中，您将学习Kafka体系结构的设计哲学和原理zookeeper在Kafka中的作用Kafka控制器的实现原理导出Kafka Network的原理以尽可能地制造产品。 一个作品很重要。 这是别人认识你的窗口。 如果可能的话，给自己打开公众号和博客，记录每天的见闻和思考。 一开始很乱很不逻辑，但坚持下去一定有很大的价值。
Architecture了解Kafka体系结构是了解Kafka的各种组件的概念以及这些组件之间的关系。 首先让我们简单地看看每个组件及其简要说明。
他们Producer :生产者，请不要试图记住发送消息的一方。 生产者创建消息并将其发送到Kafka。
Consumer:消费者，接收消息的一方。 消费者连接Kafka接收消息，进行适当的业务逻辑处理。
Consumer Group人的消费群体可以包括一个或多个消费者。 使用多区域多消费者方式，可以大大提高数据下游的处理速度，同一消费群的消费者不会重复消费消息，同样不同消费群的消费者消息不会相互影响。 Kafka通过消费群体的方式实现消息P2P模式和广播模式。
Broker:服务代理节点。 Broker是Kafka的服务节点，也就是Kafka的服务器。
Topic: Kafka消息按主题分类，生产者向特定的主题发送消息，消费者订阅和消费主题消息。
Partition: Topic是一个逻辑概念，可以细分为多个分区，每个分区都属于一个主题。 同一主题下不同分区中包含的消息不同，分区被视为可在存储级别添加的日志文件，并且在将消息添加到分区日志文件时会分配特定的“偏移”(offset )。
Offset: offset是分区中消息的唯一标识符，Kafka确保消息在分区中的顺序，但offset不超过分区。 也就是说，Kafka保证分区的顺序，而不是主题的顺序。
Replication:拷贝是Kafka保证数据高可用性的方法。 Kafka的同一分区的数据可以位于多个Broker中，通常只有主副本向外提供读写服务，如果主副本所在的Broker崩溃或发生网络异常，Kafka就会连接
Record:实际写入和读取Kafka的消息记录。 每个记录都包含密钥、值和时间戳。
我也自然记得，如果我们理解了，我们就应该通过理解来记住它们。
生产者-消费者生产者-消费者是设计模型，通过在生产者和消费者之间添加中间组件来断开连接。 生产者在中间组件上生成数据，消费者消耗数据。
就像哥哥读书的时候给tydjm写情书一样，这里哥哥是生产者，情书是新闻，tydjm是消费者。 但是有时候tydjm不在，或者很忙，哥哥也很害羞，不能直接把情书塞进tydjm的手里，把情书塞进tydjm的抽屉里。 抽屉是这个中间零件。
程序通常使用Queue作为此中间组件。 可以使用多线程将数据写入队列，另一个消费者线程可以按顺序读取和消耗队列中的数据。 模型如下图所示。
生产者-消费者模型通过添加中间层，不仅可以将生产者与消费者解除结合，便于扩展，还可以将调用和消息缓冲等异步化。
分布式队列
后来 哥和tydjm异地了， 哥在卷都奋斗，tydjm在魔都逛街。于是只能通过邮局寄暧昧信了。这样 哥、邮局和tydjm就成了分布式的了。 哥将信件发给邮局，tydjm从邮局拿到 哥写的信，再回去慢慢看。
Kafka 的消息生产者就是Producer，上游消费者进程添加 Kafka Client 创建 Kafka Producer，向 Broker 发送消息，Broker 是集群部署在远程服务器上的 Kafka Server 进程，下游消费者进程引入 Kafka Consumer API 持续消费队列中消息。
因为 Kafka Consumer 使用 Poll 的模式，需要 Consumer 主动拉去消息。所有tydjm只能定期去邮局拿信件了(呃，果然主动权都在tydjm手上啊)。
邮局不能只为 哥服务，虽然 哥一天写好几封信。但也无法挽回邮局的损失。所以邮局是可以供任何人寄信。只需要寄信人写好地址(主题)，邮局建有两地的通道就可以发收信件了。
Kafka 的 Topic 才相当于一个队列，Broker 是所有队列部署的机器。可以按业务创建不同的 Topic，Producer 向所属业务的 Topic 发送消息，相应的 Consumer 可以消费并处理消息。
由于 哥写的信太多，一个邮局已经无法满足 哥的需求，邮政公司只能多建几个邮局了，哥将信件按私密度分类(分区策略)，从不同的邮局寄送。
同一个 Topic 可以创建多个分区。理论上分区越多并发度越高，Kafka 会根据分区策略将分区尽可能均衡的分布在不同的 Broker 节点上，以避免消息倾斜，不同的 Broker 负载差异太大。分区也不是越多越好哦，毕竟太多邮政公司也管理不过来。
为防止由于邮局的问题，比如交通断啦，邮车没油啦。导致 哥的暧昧信无法寄到tydjm手上，使得 哥晚上远程跪键盘。邮局决定将 哥的信件复制几份发到多个正常的邮局，这样只要有一个邮局还在，tydjm就可以收到哥的信了。
Kafka 采用分区副本的方式来保证数据的高可用，每个分区都将建立指定数量的副本数，kakfa 保证同一分区副本尽量分布在不同的 Broker 节点上，以防止 Broker 宕机导致所有副本不可用。Kafka 会为分区的多个副本选举一个作为主副本(Leader)，主副本对外提供读写服务，从副本(Follower)实时同步 Leader 的数据。
哎，哥的信件满天飞，tydjm天天跑邮局，还要一一拆开看，哥写的信又臭又长，让tydjm忙得满身大汉大汗。于是tydjm啪的一下，很快啊，变出多个分身去不同的邮局取信，这样tydjm终于可以挤出额外的时间逛街了。
广播消息邮局最近提供了定制明信片业务，每个人都可以设计明信片，同一个身份只能领取一种明信片。哥设计了一堆，广播给所有漂亮的小妹妹都可以来领取，寒冷的棉花糖啪变出的分身也可以来领取，但是同一个身份的多个分身只能取一种明信片。
Kafka 通过 Consumer Group 来实现广播模式消息订阅，即不同 group 下的 consumer 可以重复消费消息，相互不影响，同一个 group 下的 consumer 构成一个整体。
最后我们完成了 Kafka 的整体架构，如下：
Zookeeper 是一个成熟的分布式协调服务，它可以为分布式服务提供分布式配置服、同步服务和命名注册等能力.。对于任何分布式系统，都需要一种协调任务的方法。Kafka 是使用 ZooKeeper 而构建的分布式系统。但是也有一些其他技术（例如 Elasticsearch 和 MongoDB）具有其自己的内置任务协调机制。
Kafka 将 Broker、Topic 和 Partition 的元数据信息存储在 Zookeeper 上。通过在 Zookeeper 上建立相应的数据节点，并监听节点的变化，Kafka 使用 Zookeeper 完成以下功能：
Kafka Controller 的 Leader 选举Kafka 集群成员管理Topic 配置管理分区副本管理我们看一看 Zookeeper 下 Kafka 创建的节点，即可一目了然的看出这些相关的功能。
Controller
Controller 是从 Broker 中选举出来的，负责分区 Leader 和 Follower 的管理。当某个分区的 leader 副本发生故障时，由 Controller 负责为该分区选举新的 leader 副本。当检测到某个分区的 ISR(In-Sync Replica)集合发生变化时，由控制器负责通知所有 broker 更新其元数据信息。当使用kafka-topics.sh脚本为某个 topic 增加分区数量时，同样还是由控制器负责分区的重新分配。
Kafka 中 Contorller 的选举的工作依赖于 Zookeeper，成功竞选为控制器的 broker 会在 Zookeeper 中创建/controller这个临时（EPHEMERAL）节点。
选举过程
Broker 启动的时候尝试去读取/controller节点的brokerid的值，如果brokerid的值不等于-1，则表明已经有其他的 Broker 成功成为 Controller 节点，当前 Broker 主动放弃竞选；如果不存在/controller节点，或者 brokerid 数值异常，当前 Broker 尝试去创建/controller这个节点，此时也有可能其他 broker 同时去尝试创建这个节点，只有创建成功的那个 broker 才会成为控制器，而创建失败的 broker 则表示竞选失败。每个 broker 都会在内存中保存当前控制器的 brokerid 值，这个值可以标识为 activeControllerId。
Controller 读取 Zookeeper 中的节点数据，初始化上下文(Controller Context)，并管理节点变化，变更上下文，同时也需要将这些变更信息同步到其他普通的 broker 节点中。Controller 通过定时任务，或者监听器模式获取 zookeeper 信息，事件监听会更新更新上下文信息，如图所示，Controller 内部也采用生产者-消费者实现模式，Controller 将 zookeeper 的变动通过事件的方式发送给事件队列，队列就是一个LinkedBlockingQueue，事件消费者线程组通过消费消费事件，将相应的事件同步到各 Broker 节点。这种队列 FIFO 的模式保证了消息的有序性。
Controller 被选举出来，作为整个 Broker 集群的管理者，管理所有的集群信息和元数据信息。它的职责包括下面几部分：
处理 Broker 节点的上线和下线，包括自然下线、宕机和网络不可达导致的集群变动，Controller需要及时更新集群元数据，并将集群变化通知到所有的 Broker 集群节点；创建 Topic 或者 Topic 扩容分区，Controller 需要负责分区副本的分配工作，并主导 Topic 分区副本的
Leader 选举。管理集群中所有的副本和分区的状态机，监听状态机变化事件，并作出相应的处理。Kafka分区和副本数据采用状态机的方式管理，分区和副本的变化都在状态机内会引起状态机状态的变更，从而触发相应的变化事件。
65 哥：状态机啊，听起来好复杂。
Controller 管理着集群中所有副本和分区的状态机。大家不要被状态机这个词唬住了。理解状态机很简单。先理解模型，即这是什么关于什么模型，然后就是模型的状态有哪些，模型状态之间如何转换，转换时发送相应的变化事件。
Kafka 的分区和副本状态机很简单。我们先理解，这分别是管理 Kafka Topic 的分区和副本的。它们的状态也很简单，就是 CRUD，具体说来如下：
分区状态机PartitionStateChange，管理 Topic 的分区，它有以下 4 种状态：
NonExistentPartition：该状态表示分区没有被创建过或创建后被删除了。NewPartition：分区刚创建后，处于这个状态。此状态下分区已经分配了副本，但是还没有选举 leader，也没有 ISR 列表。OnlinePartition：一旦这个分区的 leader 被选举出来，将处于这个状态。OfflinePartition：当分区的 leader 宕机，转移到这个状态。我们用一张图来直观的看看这些状态是如何变化的，以及在状态发生变化时 Controller 都有哪些操作：
副本状态机
ReplicaStateChange，副本状态，管理分区副本信息，它也有 4 种状态：
NewReplica: 创建 topic 和分区分配后创建 replicas，此时，replica 只能获取到成为 follower
状态变化请求。
OnlineReplica: 当 replica 成为 parition 的 assingned replicas 时，其状态变为
OnlineReplica, 即一个有效的 OnlineReplica。
OfflineReplica: 当一个 replica 下线，进入此状态，这一般发生在 broker 宕机的情况下；
NonExistentReplica: Replica 成功删除后，replica 进入 NonExistentReplica 状态。
副本状态间的变化如下图所示，Controller 在状态变化时会做出相应的操作：
Kafka 的网络通信模型是基于 NIO 的 Reactor 多线程模型来设计的。其中包含了一个Acceptor线程，用于处理新的连接，Acceptor 有 N 个 Processor 线程 select 和 read socket 请求，N 个 Handler 线程处理请求并相应，即处理业务逻辑。下面就是 KafkaServer 的模型图：