小生的博客

为了解决只使用高水位而导致数据丢失或数据不一致的问题，Kafka 引入了Leader Epoch。Leader Epoch，可以认为是 Leader 版本。它由两部分数据组成：Broker 会在内存中为每个分区都缓存 Leader Epoch 数据，同时它还会定期地将这些信息持久化到一个 checkpoint 文件中。当 Leader 副本写入消息到磁盘时，Broker 会尝试更新这部分缓存。如果该 Leader 是首次写入消息，那么 Broker 会向缓存中增加一个 Leader Epoch 条目，否则就

HW即，高水位，经典定义如下：「在时刻 T，任意创建时间为 T’，且 T′≤TT'≤TT′≤T 的所有事件都已经到达或被观测到，那么 T 就被定义为水位」。一般而言高水位都用时间戳来表示，但是Kafka中并不是这样做的，在Kafka中高水位是用位置信息即消息位移来表示的。高水位以下的消息被认为是已提交消息，反之就是未提交消息。消费者只能消费已提交消息 → 等于HW的也是不能被消费的。 表示副本写入下一条消息的位移值。介于高水位和 LEO 之间的消息就属于未提交消息。 → 同一个副本对象，其高水位值不会大于

首先，无论是 Kafka 客户端还是 Broker 端，它们之间的交互都是通过请求-响应的方式完成的。Kafka 自己定义了一套请求协议，用于实现各种各样的交互操作，所有的请求都是通过 TCP 以 Socket进行通讯的。比如 请求是用于生产消息的， 请求是用于消费消息的， 请求是用于请求 Kafka 集群元数据信息的。因为采用顺序请求的方式吞吐量太低，采用每个请求对应一个线程的方式开销太大，所以Kafka采用Reactor设计模式(1 + M + N) → 经典高并发IO设计模式 来处理请求。在这个架构

概述Kafka目前支持GZIP、Snappy、LZ4、zstd、不压缩这几种压缩算法。在开启压缩时，Kafka会选择一个batch的消息一起压缩，这样的一批消息就是一个压缩分段，我们也可以通过参数来控制每批消息的大小。在 Kafka 中，生产者生成一个压缩分段发给broker，在broker中是不会解压这个压缩分段的（因为在kafka中一个batch的消息在broker中是不会拆分的，自然也不会进行解压），最后压缩分段由消费者进行解压。Kafka通过这种设计，降低了broker中CPU资源的消耗，同时