kafka相关知识

首先，为什么使用kafka？

削峰填谷。缓冲上下游瞬时突发流量，保护“脆弱”的下游系统不被压垮，避免引发全链路服务“雪崩”。
系统解耦。发送方和接收方的松耦合，一定程度简化了开发成本，减少了系统间不必要的直接依赖。

kafka名词解释

**Broker：**接收客户端发送过来的消息，对消息进行持久化
**主题：Topic。**主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务。
**分区：Partition。**一个有序不变的消息序列。每个主题下可以有多个分区。
**消息：**这里的消息就是指 Kafka 处理的主要对象。
**消息位移：Offset。**表示分区中每条消息的位置信息，是一个单调递增且不变的值。
****副本：Replica。****Kafka 中同一条消息能够被拷贝到多个地方以提供数据冗余，这些地方就是所谓的副本。副本还分为领导者副本和追随者副本，各自有不同的角色划分。每个分区可配置多个副本实现高可用。一个分区的N个副本一定在N个不同的Broker上。
**生产者：Producer。**向主题发布新消息的应用程序。
**消费者：Consumer。**从主题订阅新消息的应用程序。
**消费者位移：Consumer Offset。**表示消费者消费进度，每个消费者都有自己的消费者位移。offset保存在broker端的内部topic中，不是在clients中保存
**消费者组：Consumer Group。**多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐。
**重平衡：Rebalance。**消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区

ZooKeeper 在里面的职责是什么？

它是一个分布式协调框架，负责协调管理并保存 Kafka 集群的所有元数据信息，比如集群都有哪些 Broker 在运行、创建了哪些 Topic，每个 Topic 都有多少分区以及这些分区的 Leader 副本都在哪些机器上等信息。

消息传输的格式

纯二进制的字节序列。当然消息还是结构化的，只是在使用之前都要将其转换成二进制的字节序列。

消息传输协议

**点对点模型。**系统 A 发送的消息只能被系统 B 接收，其他任何系统都不能读取 A 发送的消息
**发布/订阅模型。**该模型也有发送方和接收方，只不过提法不同。发送方也称为发布者（Publisher），接收方称为订阅者（Subscriber）。和点对点模型不同的是，这个模型可能存在多个发布者向相同的主题发送消息，而订阅者也可能存在多个，它们都能接收到相同主题的消息。

消息压缩

生产者程序中配置compression.type 参数即表示启用指定类型的压缩算法。

props.put(“compression.type”, “gzip”)，它表明该 Producer 的压缩算法使用的是GZIP。这样 Producer 启动后生产的每个消息集合都是经 GZIP 压缩过的，故而能很好地节省网络传输带宽以及 Kafka Broker 端的磁盘占用。

但如果Broker又指定了不同的压缩算法，如：Snappy，会将生产端的消息解压然后按自己的算法重新压缩。

各压缩算法比较：吞吐量方面：LZ4 > Snappy > zstd 和 GZIP；而在压缩比方面，zstd > LZ4 > GZIP > Snappy。
kafka默认不指定压缩算法。

消息解压缩

当 Consumer pull消息时，Broker 会原样发送出去，当消息到达 Consumer 端后，由 Consumer 自行解压缩还原成之前的消息。

分区策略

编写一个类实现org.apache.kafka.clients.Partitioner接口。实现内部两个方法：partition()和close()。然后显式地配置生产者端的参数partitioner.class

常见的策略：

轮询策略（默认）。保证消息最大限度地被平均分配到所有分区上。
随机策略。随机策略是老版本生产者使用的分区策略，在新版本中已经改为轮询了。
按key分区策略。key可能是uid或者订单id，将同一标志位的所有消息都发送到同一分区，这样可以保证一个分区内的消息有序
其他分区策略。如：基于地理位置的分区策略

幂等性 Producer

设置参数props.put(“enable.idempotence”, ture)，Producer 自动升级成幂等性 Producer，其他所有的代码逻辑都不需要改变。Kafka 自动帮你做消息的重复去重。

原理很简单，就是经典的空间换时间，即在 Broker 端多保存一些字段。当 Producer 发送了具有相同字段值的消息后，Broker 能够自动知晓这些消息已经重复了，可以在后台默默地把它们“丢弃”掉。

只能保证单分区、单会话上的消息幂等性。一个幂等性 Producer 能够保证某个topic的一个分区上不出现重复消息，但无法实现多个分区的幂等性。比如采用轮询，下一次提交换了一个分区就无法解决

事务型 Producer

能够保证将消息原子性地写入到多个分区中。这批消息要么全部写入成功，要么全部失败。能够保证跨分区、跨会话间的幂等性。

producer.initTransactions();
try {
            producer.beginTransaction();
            producer.send(record1);
            producer.send(record2);
            //提交事务
            producer.commitTransaction();
} catch (KafkaException e) {
            //事务终止
            producer.abortTransaction();
}

实际上即使写入失败，Kafka 也会把它们写入到底层的日志中，也就是说 Consumer 还是会看到这些消息。要不要处理在 Consumer 端设置 isolation.level ，这个参数有两个值:

read_uncommitted：这是默认值，表明 Consumer 能够读取到 Kafka 写入的任何消息
read_committed：表明 Consumer 只会读取事务型 Producer 成功提交事务写入的消息

Kafka Broker 是如何存储数据？

Kafka 使用消息日志（Log）来保存数据，一个日志就是磁盘上一个只能追加写（Append-only）消息的物理文件。因为只能追加写入，故避免了缓慢的随机 I/O 操作，改为性能较好的顺序 I/O 写操作，这也是实现 Kafka 高吞吐量特性的一个重要手段。

不过如果你不停地向一个日志写入消息，最终也会耗尽所有的磁盘空间，因此 Kafka 必然要定期地删除消息以回收磁盘。怎么删除呢？

简单来说就是通过日志段（Log Segment）机制。在 Kafka 底层，一个日志又近一步细分成多个日志段，消息被追加写到当前最新的日志段中，当写满了一个日志段后，Kafka 会自动切分出一个新的日志段，并将老的日志段封存起来。Kafka 在后台还有定时任务会定期地检查老的日志段是否能够被删除，从而实现回收磁盘空间的目的。