Kafka、RabbitMQ、RocketMQ 之间的区别是什么 ?
总的来说，三大原因，语言、潮流、生态。
rpc和mq是分布式大厦门口最基础的两块砖。
流式处理的简介
流式处理对实时性要求很高
流处理需要和时间打交道，尤其在用于流分析时，如 “最近 5 分钟的平均值”，这个 “最后 5 分钟” 的定义其实非常模糊，处理起来非常麻烦。
kafka基本概念
Topics
一个主题可以横跨多个 broker，以此来提供比单个 broker 更强大的性能。
Partition
一个分区只属于单个主题。
同一主题下的不同分区包含的消息是不同的，分区在存储层面可以看作一个可追加的日志（Log）文件，消息在被追加到分区日志文件的时候都会分配一个特定的偏移量（offset）。
offset 是消息在分区中的唯一标识，Kafka 通过它来保证消息在分区内的顺序性，不过 offset 并不跨越分区，也就是说，Kafka 保证的是 $\color{green}{\text{分区有序}}$ 而不是主题有序。
每一条消息被发送到 broker 之前，会根据分区规则选择存储到哪个具体的分区。如果分区规则设定得合理，所有的消息都可以均匀地分配到不同的分区中。如果一个主题只对应一个文件，那么这个文件所在的机器I/O将会成为这个主题的性能瓶颈，而分区解决了这个问题。在创建主题的时候可以通过指定的参数来设置分区的个数，当然也可以在主题创建完成之后去修改分区的数量，通过增加分区的数量可以实现水平扩展。
Partition offset
Replicas of partition
Brokers
Leader
Follower
kafka面试题
Zookeeper 对于 Kafka 的作用是什么？
Zookeeper 是一个开放源码的、高性能的协调服务，它用于 Kafka 的分布式应用。
Zookeeper 主要用于在集群中不同节点之间进行通信。
在 Kafka 中，它被用于提交偏移量，因此如果节点在任何情况下都失败了，它都可以从之前提交的偏移量中获取除此之外，它还执行其他活动，如: leader 检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。
Kafka 判断一个节点是否还活着有那两个条件？
（1）节点必须可以维护和 ZooKeeper 的连接，Zookeeper 通过心跳机制检查每个节点的连接
（2）如果节点是个 follower,他必须能及时的同步 leader 的写操作，延时不能太久
数据传输的事务定义有哪三种？
和 MQTT 的事务定义一样都是 3 种。
（1）最多一次: 消息不会被重复发送，最多被传输一次，但也有可能一次不传输
（2）最少一次: 消息不会被漏发送，最少被传输一次，但也有可能被重复传输.
（3）精确的一次（Exactly once）: 不会漏传输也不会重复传输,每个消息都传输被一次而且仅仅被传输一次，这是大家所期望的。
Kafka 与传统 MQ 消息系统之间有三个关键区别
(1).Kafka 持久化日志，这些日志可以被重复读取和无限期保留
(2).Kafka 是一个分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据提升容错能力和高可用性
(3).Kafka 支持实时的流式处理
讲一讲 kafka 的 ack 的三种机制
request.required.acks 有三个值 0 1 -1(all)
0:生产者不会等待 broker 的 ack，这个延迟最低但是存储的保证最弱当 server 挂掉的时候就会丢数据。
1：服务端会等待 ack 值 leader 副本确认接收到消息后发送 ack 但是如果 leader挂掉后他不确保是否复制完成新 leader 也会导致数据丢失。
-1(all)：服务端会等所有的 follower 的副本受到数据后才会受到 leader 发出的ack，这样数据不会丢失
经验
参考文献
堆积告警的理解
Kafka 中的消费组是消费者的集合，它们共享一个公共ID，这个ID被称为消费组ID。消费组是实现负载均衡和故障转移等机制的重要因素。
“消费组堆积”是指消费组中的消费者无法及时处理接收到的消息，导致消息在Kafka中的滞留时间过长，从而形成了”积压”。
而Kafka的主题（Topic）是消息的类别或者说是消息的存储地址，生产者把消息发送到特定的主题，消费者从主题中读取消息。说“主题没有堆积这个说法”是因为主题是一个生产者生产数据，消费者消费数据的中间场所，中间本身不会积压，积压是生产者生产的速度超过消费者消费的速度导致的。
所以，这句话的含义是，Kafka的主题本身不会有”堆积”的现象，堆积发生在消费组这个层次。
一个Kafka的Topic可以有多个消费组。每个消费组包含一个或多个消费者。
当一个Topic有多个消费组的时候，这个Topic内的每一条数据消息将被发送到每一个消费组。但在每个消费组内部，它们将根据一定的策略分配给不同的消费者。这意味着，一个消息可以被多个消费组内的消费者接收和处理，但在一个消费组内只会被一个消费者消费。这种设计可以支持同时处理多种类型的消费操作。
Kafka 不直接记录每个消费组的堆积情况，而是跟踪消费者进度。消费者进度被称为消费者位移（Consumer Offsets），它能够帮助我们了解消费组的堆积情况。消费者位移是一个数字，表示消费者消费消息在 Topic 的 Partition 中的位置。消费者位移会被定期提交给 Kafka 服务器。
在 Apache Kafka 0.9 之后，消费者位移被存储在一个名为 __consumer_offsets 的内置 Topic 内部，而不是一些日志文件中。当消费者开始消费一个 Topic 时，会从这个内置 Topic 中获取它在每个 Partition 中的位移，然后从这个位置开始消费消息。
要计算消费组的堆积情况，我们可以获取 Topic 的每个 Partition 的末尾（当前可用的最新消息的位移）与消费组在这些 Partition 中已消费的位移之差。当差值变大时，就可以认为是堆积发生了。
有一些开源工具和监控系统，例如 Kafka Manager、Burrow 或者 Confluent Control Center，可以帮助我们监控和管理消费组的堆积情况。