kafka底层原理分析

Posted 2021-06-28 苍山有雪，剑有霜

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了kafka底层原理分析相关的知识，希望对你有一定的参考价值。

Kafka是由Linkedin公司开发的一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据。

文章目录

kafka具有众多良好的特性：

高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒
可扩展性： kafka集群支持热扩展
持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
高并发：支持数千个客户端同时读写

那么Kafka为什么如此一枝独秀？

系统架构

Kafka如此优良的特性来源于它良好的架构设计：

在上图中：

Producer：消息的生产者；
Kafka Cluster：运行Kafka实例的集群；
Broker：一个kafka实例，可认为就是一台服务器；
Topic：消息的分类主题；
Partition：消息的分区，是指同一个topic的消息被分成了多个部分，减小了单独brokr的压力，实现负载均衡，不同分区的数据是不同的；（注：分区的好处除了负载均衡，还有就是便于水平扩展）
Follower、Leader：前者是备份，后者是主体，只有当主体出现故障时，才会选择一个备份（replica）作为新的主体；（注：主体和备份必定不在同一个实例上）
Consumer （Group）：消息的消费者，多个消费者组成一个Group，kafka规定同一个Topic的消息只能被同一个消费者组的消费者消费；（提高吞吐量！）
Zookeeper：保存集群的信息，保证分布式系统的可用性；

工作流程

发送数据的流程如下：

从上图可知有几点需要注意：

信息是往Leader传输的；
follower是主动pull消息的；
只有follower完成了backup，才算是一次正常的消息发送；（保证消息不会丢失）

有一个问题，消息发送到哪一个partition呢？

如果消息中指定了Partition id，那就发送到对应的partition；
如果没有，那就消息的key进行hash一下；
如果id和key都没有，那就随机；

另外，kafka备份策略的的可以配置的，ACK可以配置为：0、1、all。

0表示不需要ACK，安全性低效率高；
1表示需要一个ACK才会继续下一条；（一个follower接收就可以）
all表示所有的follower都完成才会继续下一条，效率最低；

**保存数据时，**kafka预先在磁盘开辟一块空间，而后顺序写入数据（比随机快多了），上文说topic是以partition的形式分布于集群中的，而partition表现为一个一个的文件夹，其中包含了多个segment文件夹，而segment下包含.index .log .timeindex文件（后者为新增的版本特性）。

其中，index和timeindex为索引文件，log为实际存储message的文件。注意到每一个文件前都有一串序号，这就是kafka提高查找效率的方式——分段+索引。

log文件存储了message的三个重要属性：offset、消息大小、真正的消息数据。

那么消费者是如何读取到特定的消息的呢？

需要注意的是：（怎么通知的？）

消费者拉取数据时，也是从leader拉；
多个partition可以被一个consumer消费，但是反之不行；

在读取消息时，需要通过offset从partiton中读取到相应的消息体，例如查找offset为368801的message，具体的过程详见：Kafka基本原理。

这套机制是建立在offset为有序的基础上，利用segment+有序offset+稀疏索引+二分查找+顺序查找等多种手段来高效的查找数据！那么消费者如何知道自己消费了多少？以前，是放在zookeeper中，但可能造成重复消费，现在是存放在kafka集群的__consumer_offsets这个专有topic中。

有一篇讲解kafkapartition和consumer之间的关系：stackflow