控制器

1. 控制器（Controller）是Kafka的核心组件，主要作用是在ZK的帮助下管理和协调整个Kafka集群
2. 集群中任一Broker都能充当控制器的角色，但在运行过程中，只能有一个Broker成为控制器，行使管理和协调的职责

1
2
3
4
5
6
7
8
9
10
11
12
13

[zk: localhost:2181(CONNECTED) 1] get /controller
{"version":1,"brokerid":0,"timestamp":"1571311742367"}
cZxid = 0xd68
ctime = Thu Oct 17 19:29:02 CST 2019
mZxid = 0xd68
mtime = Thu Oct 17 19:29:02 CST 2019
pZxid = 0xd68
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x1000209974b0000
dataLength = 54
numChildren = 0

饿汉模式

class

1
2
3
4
5
6
7
8
9
10
11

// 饿汉模式
public final class Singleton {
    private static Singleton instance = new Singleton();

    private Singleton() {
    }

    public static Singleton getInstance() {
        return instance;
    }
}

触发重平衡

1. 组成员数量发生变化 – 最常见
2. 订阅主题数量发生变化
3. 订阅主题的分区数发生变化

请求协议

1. Kafka自定义了一组请求协议，用于实现各种各样的交互操作
   • PRODUCE请求用于生产消息，FETCH请求用于消费消息，METADATA请求用于请求Kafka集群元数据信息
2. Kafka 2.3总共定义了45种请求格式，所有请求都通过TCP网络以Socket的方式进行通讯

副本机制的优点

1. 提供数据冗余
   • 即使系统部分组件失效，系统依然能够继续运转，增加了整体可用性和数据持久性
2. 提供高伸缩性
   • 支持横向扩展，能够通过增加机器的方式来提升读性能，进而提高读操作吞吐量
3. 改善数据局部性
   • 允许将数据放入与用户地理位置相近的地方，从而降低系统延时
4. Kafka只能享受副本机制提供数据冗余实现的高可用性和高持久性

JVM内存分配性能问题

1. JVM内存分配不合理最直接的表现就是频繁的GC，这会导致上下文切换，从而降低系统的吞吐量，增加系统的响应时间

对象在堆中的生命周期

1. 在JVM内存模型的堆中，堆被划分为新生代和老年代
   • 新生代又被进一步划分为Eden区和Survivor区，Survivor区由From Survivor和To Survivor组成
2. 当创建一个对象时，对象会被优先分配到新生代的Eden区
   • 此时JVM会给对象定义一个对象年轻计数器（-XX:MaxTenuringThreshold）
3. 当Eden空间不足时，JVM将执行新生代的垃圾回收（Minor GC）
   • JVM会把存活的对象转移到Survivor中，并且对象年龄+1
   • 对象在Survivor中同样也会经历Minor GC，每经历一次Minor GC，对象年龄都会+1
4. 如果分配的对象超过了-XX:PetenureSizeThreshold，对象会直接被分配到老年代

Consumer Lag

1. Consumer Lag（滞后程度）：消费者当前落后于生产者的程度
2. Lag的单位是消息数，一般是在主题的级别上讨论Lag，但Kafka是在分区的级别上监控Lag，因此需要手动汇总
3. 对于消费者而言，Lag是最重要的监控指标，直接反应了一个消费者的运行情况
   • 一个正常工作的消费者，它的Lag值应该很小，甚至接近于0，滞后程度很小
   • 如果Lag很大，表明消费者无法跟上生产者的速度，Lag会越来越大
     • 极有可能导致消费者消费的数据已经不在操作系统的页缓存中了，这些数据会失去享有Zero Copy技术的资格
     • 这样消费者不得不从磁盘读取这些数据，这将进一步拉大与生产者的差距
     • 马太效应：Lag原本就很大的消费者会越来越慢，Lag也会也来越大

创建TCP连接

1. 消费者端的主要程序入口是KafkaConsumer，但构建KafkaConsumer实例不会创建任何TCP连接
   • 构建KafkaProducer实例时，会在后台默默地启动一个Sender线程，Sender线程负责Socket连接的创建
   • 在Java构造函数中启动线程，会造成this指针逃逸，是一个隐患
2. 消费者的TCP连接是在调用KafkaConsumer.poll方法时被创建的，poll方法内部有3个时机可以创建TCP连接

编译

1. 前端编译：即常见的.java文件被编译成.class文件的过程
2. 运行时编译：机器无法直接运行Java生成的字节码，在运行时，JIT或者解释器会将字节码转换为机器码
   • 类文件在运行时被进一步编译，可以变成高度优化的机器代码
3. C/C++编译器的所有优化都是在编译期完成的，运行期的性能监控仅作为基础的优化措施是无法进行的
4. JIT编译器是JVM中运行时编译最重要的部分之一

Kafka Java Consumer设计原理

1. Kafka Java Consumer从Kafka 0.10.1.0开始，KafkaConsumer变成了双线程设计，即用户主线程和心跳线程
   • 用户主线程：启动Consumer应用程序main方法的那个线程
   • 心跳线程：只负责定期给对应的Broker机器发送心跳请求，以标识消费者应用的存活性
2. 引入心跳线程的另一个目的
   • 将心跳频率和主线程调用KafkaConsumer.poll方法的频率分开，解耦真实的消息处理逻辑和消费组成员存活性管理
3. 虽然有了心跳线程，但实际的消息获取逻辑依然是在用户主线程中完成
   • 因此在消费消息的这个层面，依然可以安全地认为KafkaConsumer是单线程的设计
4. 老版本Consumer是多线程的架构
   • 每个Consumer实例在内部为所有订阅的主题分区创建对应的消息获取线程，即Fetcher线程
5. 老版本Consumer同时也是阻塞式的，Consumer实例启动后，内部会创建很多阻塞式的消息获取迭代器
   • 但在很多场景下，Consumer端有非阻塞需求，如在流处理应用中执行过滤、分组等操作就不能是阻塞式的
   • 基于这个原因，社区为新版本Consumer设计了单线程+轮询的机制，该机制能较好地实现非阻塞的消息获取
6. 单线程的设计简化了Consumer端的设计
   • Consumer获取到消息后，处理消息的逻辑是否采用多线程，完全由使用者决定
7. 不论使用哪一种编程语言，单线程的设计都比较容易实现
   • 并不是所有的编程语言都能很好地支持多线程，而单线程设计的Consumer更容易移植到其他语言上