kafka无疑是当今互联网公司使用最广泛的分布式实时消息流系统，它的高吞吐量，高可靠等特点为并发下的大批量实时请求处理提供了可靠保障。很多同学在项目中都用到过kafka，但是对kafka的设计原理以及处理机制并不是十分清楚。为了知其然知其所以然，本文主要从三个方面介绍kafka，第一，kafka简介以及适用场景，第二，kafka设计原理，三，常见问题及思考。

一、kafka 简介及适用场景

**kafka 官网上对 kafka 的定义：**一个分布式发布-订阅消息传递系统。主要特点包括高吞吐量、持久化（消息持久化到磁盘，支持批量和实时处理）、可扩展性、容错性。

kafka 相关术语：

Message（消息）：基本数据单元（key-value 形式）。为了提高效率，消息被分批次写入 kafka。批次就是一组消息，这些消息属于同一个 Topic 和 Partition。

Topic（主题）：每条消息都有一个类别，这个类别被称为 Topic。Topic 类似于数据库的表或者一个文件夹，物理上不同 Topic 的消息分开存储。

Partition（分区）：每个 Topic 包含一个或多个 Partition。Partition 是物理概念，通常，一个 Topic 的消息被均匀地分发到每个 partition，以追加的方式写入，先入先出的顺序读取。注：由于一个主题一般包含几个分区，因此无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区的顺序。

Offst(偏移量)：单个分区中的每一条消息都被分配一个 Offset，它是一个单调递增的整型数，可用来作为分区中消息的唯一标识符。

Broker（缓存代理）：kafka 集群包含一个或多个服务器，这种服务器被称为 broker。不维护任何消息的状态。

Producer（生产者）：负责发布消息到 kafka broker。

Consumer（消费者）：消息消费者，向 kafka broker 读取消息的客户端。

Consumer Group（消费组）：每个 Consumer 属于一个特定的 Consumer Group。注：一个分区消息只能被一个 Consumer Group 中的一个 Consumer 消费。一个 Consumer 可以消费多个 Topic 的消息。每个 Group 中 Consumer 消息消费独立。具体理解见下图，第三部分的常见问题 2 给出了解释。

kafka 使用场景

1）push 发送

2）高吞吐量

3）可以作为大缓冲区使用

4）Hadoop 或传统的数据仓库中存储消息用于离线分析

5）nginx 日志收集

二、kafka 设计原理

一个简单的 kafka 集群架构如下图所示

从图中可以看到，生产者将数据发送(push)到 Broker 代理，Broker 代理有多个 topic，消费者主动从 Broker 获取(pull)数据。为什么采取 Broker 拉去数据的方式，下面的思考问题会给出答案。在发送，拉去过程中 kafka 的一些机制如下。

1、Message-partition 的分配机制

1）Key 不为空时：对 key 进行 hash 后对分区数量取余运算，保证了同一个 key 会被分到同一个分区。

2）key 为空，则进行轮询发送。

2、kafka 默认的消息保留策略

要么保留一段时间，要么保留到到消息达到一定大小的字节数。

**3、kafka 消息处理机制 **

1） 发送到 partitions 中的消息将会按照它接收的顺序追加到日志中。

2）对于消费者而言,它们消费消息的顺序和日志中消息顺序一致。

3）如果 Topic 的“replication factor”（复制因子）为 N,那么允许 N-1 个 kafka 实例失效，比如 3 副本的设置允许 2 个副本失效。

4）kafka 提供 at-least-once（至少一次） delivery,即当 consumer 宕机后，有些消息可能会被重复 delivery。

5）因每个 partition 只会被 consumer group 内的一个 consumer 消费，故 kafka 保证每个 partition 内的消息会被顺序的消费。

6）ack 校验，当消费者消费成功，返回 ack 信息。

三、常见问题及思考

1、为什么 Broker 为什么不主动推送消息，然后保存消息状态为已消费？

Broker 推送消息的方式无法很好地保证消费的处理语义。比如当我们已经把消息发送给消费者之后，由于消费进程挂掉或者由于网络原因没有收到这条消息，如果我们在消费代理将其标记为已消费，这个消息就永久丢失了。kafka 采取拉取模型(pull)，由自己控制消费速度，以及消费的进度，消费者可以按照任意的偏移量进行消费。比如消费者可以消费已经消费过的消息进行重新处理，或者消费最近的消息。

2、为什么一个分区消息只能被一个消费组中的一个消费者消费？

我们可以假设同一个消费组中的消费者 1 已经消费了 1-10，那么该分区的消费 index 需要移动到 10 的位置。当同一个消费组中的消费者 2 希望消费 10-20 时，index 再继续进行移动。

问题 1 我们已经了解了 broker 维护消息状态的以及索引的弊端。那么就需要在 consumer 端进行多个 index 维护，那么就得引入中心的概念，大家都在中心去获得当前的 index，这会增加复杂性。因此，虽然牺牲了分区的分布式消费。但是因为可以有多个分区，也是一个比较合理的方案。

3、为什么发送了消息，接收端确没有收到消息？

a、确认发送方和接收方配置的 topic 是否一致；

b、确认发送方和接收方配置的 kafka 集群是否一致（jps 命令查看集群是否启动）

c、确认发送方和接收方配置的是不是同一个 partition；

d、查看时间戳的方式确认发送方的消息是否落入到 kafka 的日志中；

d.1 没有落入相应 partition 的 kafka 日志中（即 kafka 没有接收到）

1）发送方是否有特殊配置，即一定量的消息才发送到 kafka 中（批量发送，可设置）；

2）消息没有发送成功，消息格式不正确或者 kafka 发送工具问题；

d.2kafka 日志中（即 kafka 没有接收到）

1）接收端 offset 设置有误，导致接收不到消息；

2）接收端拉取消息出现问题

四、总结

文本简述了 kafka 的简介以及原理，企业在实际使用中还会有很多新的挑战。

点击下方链接免费领取：性能测试+接口测试+自动化测试+测试开发+测试用例+简历模板+测试文档

http://qrcode.testing-studio.com/f?from=infoQ&url=https://ceshiren.com/t/topic/22265