总结:绘上一张Kakfa架构思维大纲脑图(xmind)
其实关于Kafka,能问的问题实在是太多了,扒了几天,最终筛选出44问:基础篇17问、进阶篇15问、高级篇12问,个个直戳痛点,不知道如果你不着急看答案,又能答出几个呢?
若是对Kafka的知识还回忆不起来,不妨先看我手绘的知识总结脑图(xmind不能上传,文章里用的是图片版)进行整体架构的梳理
梳理了知识,刷完了面试,如若你还想进一步的深入学习解读kafka以及源码,那么接下来的这份《手写“kafka”》将会是个不错的选择。
-
Kafka入门
-
为什么选择Kafka
-
Kafka的安装、管理和配置
-
Kafka的集群
-
第一个Kafka程序
-
Kafka的生产者
-
Kafka的消费者
-
深入理解Kafka
-
可靠的数据传递
-
Spring和Kafka的整合
-
SpringBoot和Kafka的整合
-
Kafka实战之削峰填谷
-
数据管道和流式处理(了解即可)
与那些需要几周甚至几个月才能发布更新的大公司相比,这是一个关键的优势。在高频交易领域,一个漏洞可以在几秒钟内抹掉一整年的利润,所以我们不打算在质量上做任何妥协。我们搭建了一个严格的敏捷开发环境,包括 Jenkins、Maven、单元测试、夜晚构建和 Jira,使用了很多开源库和项目。
使用 Java,开发人员可以专注于直观的面向对象业务逻辑,而不是浪费时间去调试一些晦涩的内存核心转储或管理 C++ 指针。而且,由于 Java 强大的内存管理能力,即使是初级程序员也可以在第一天加入项目时为系统带来价值,而且风险很小。
有了良好的设计模式和干净的编码习惯,Java 的速度可与 C++ 相媲美。
例如,Java 会优化和编译在应用程序运行期间观察到的最佳路径,但 C++ 会预先编译所有东西,因此即使未被使用的方法也会成为可执行二进制文件的一部分。
但是,Java 有一个问题,它让 Java 成为一门强大且令人喜爱的编程语言,但也成了 Java 的缺点之一 (至少对于微秒级应用程序来说)——Java 虚拟机 (JVM):
- Java 在运行过程中编译代码 (JIT),这意味着当它第一次运行某些代码时,会有编译延迟。
- Java 管理内存的方式是在“堆”空间中分配内存块。每隔一段时间,它就会清理空间,移除旧对象,为新对象腾出空间。主要的问题是,为了进行准确的计数,应用程序线程需要暂时“冻结”。这个过程称为垃圾回收 (GC)。
GC 是低延迟应用程序开发人员可能会放弃 Java 的主要原因。
市场上有一些可用的 Java 虚拟机。
最常见的是 Oracle Hotspot JVM,它在 Java 社区中被广泛使用,主要是一些历史原因。
对于非常苛刻的应用程序,有一个很棒的替代方案,也就是 Azul Systems 的 Zing。
Zing 是标准 Oracle Hotspot JVM 的一个强大的替代品。Zing 解决了 GC 停顿和 JIT 编译问题。
接下来,让我们来研究一下 Java 的一些固有问题和可能的解决方案。
1. 了解 Java 的 JIT 编译器
像 C++ 这样的编程语言被称为编译型语言,因为发布的代码完全是二进制的,可以直接在 CPU 上执行。
PHP 或 Perl 被称为解释型语言,因为解释器 (安装在目标机器上) 会在运行时编译每一行代码。
Java 介于两者之间,它将代码编译成 Java 字节码,并在必要时再将其编译成二进制的。
Java 不在启动时编译代码的原因与后续的性能优化有关。通过观察应用程序运行并分析实时方法调用和类初始化情况,Java 对经常被调用的代码部分进行编译。它甚至可能会根据经验做出一些假设 (某些代码永远不会被调用,或者某个对象始终是一个字符串)。
编译过的代码执行速度非常快,但有三个缺点:
- 一个方法需要被调用一定次数才能达到编译阈值,然后才能被编译和优化 (这个阈值是可配置的,通常在 10000 次左右)。在此之前,未优化的代码不会“全速”运行。在更快的编译和高质量的编译之间存在折衷 (如果假设是错误的,就会发生编译成本)。
- 当 Java 应用程序重新启动时,我们又回到了起点,必须等待再次达到阈值。
- 有些应用程序有一些不常被调用但很关键的方法,这些方法只会被调用几次,但在被调用时需要非常快。
Zing 通过让它的 JVM“保存”已编译的方法和类的状态(也就是所谓的 profile)来解决这些问题。这个独特的功能叫做 ReadyNow,也就是说 Java 应用程序可以始终以最佳速度运行,即使是在重启之后。
当你使用已有的 profile 重新启动应用程序,Azul JVM 会立即收回以前的决策并直接编译重要的方法,以解决 Java 的预热问题。
此外,你也可以在开发环境中构建一个 profile 来模拟生产行为。优化后的 profile 能部署到生产环境中,并知道所有关键路径都已经过编译和优化。
下图显示了交易应用程序 (在模拟环境中) 的最大延迟。
Hotspot JVM 的延时峰值是显而易见的,而 Zing 的延时保持得相当稳定。
百分比分布表明,在 1% 的时间内,Hotspot JVM 发生的延迟是 Zing JVM 的 16 倍。
2. 解决垃圾回收停顿问题
第二个问题是在垃圾回收期间,整个应用程序可能会停顿几毫秒到几秒钟 (延迟会随着代码复杂性和堆大小的增加而增加),更糟糕的是,你无法控制这种情况何时发生。
虽然对很多 Java 应用程序来说,暂停应用程序几毫秒甚至几秒是可以接受的,但对于低延迟应用程序来说,这是一场灾难,无论是在汽车、航空航天、医疗还是金融领域。
GC 影响对于 Java 开发人员来说是一个很大话题,Full GC 通常也叫作“停止世界的停顿(stop-the-world)”,因为它会冻结整个应用程序。
多年来,有很多 GC 算法都试图降低吞吐量 (有多少 CPU 时间用于应用程序逻辑执行而不是垃圾回收) 和 GC 停顿 (我可以暂停应用程序多长时间)。
从 Java 9 发布以来,G1 一直是默认的垃圾回收器,其主要思想是根据用户提供的时间目标对 GC 停顿进行划分。它通常提供较短的停顿时间,但以降低吞吐量为代价。此外,停顿时间随着堆的大小而增加。
Java 提供了大量的设置参数,从堆大小到回收算法以及分配给 GC 的线程数。因此,Java 应用程序通常会配置大量的参数:
很多开发人员通过各种技术来避免 GC。最主要的是,如果我们少创建一些对象,那么后续要清除的对象就越少。
一种古老的 (仍然在使用) 技术是使用对象池。例如,数据库连接池可以保存 10 个已经打开的数据库连接,以便在需要时使用。
多线程通常需要锁,这会导致同步延迟和停顿 (特别是当它们共享资源时)。一种流行的方式是使用环形缓冲队列系统,多个线程可以在一个无锁的环境中(请参考 disruptor)进行读写操作。
https://lmax-exchange.github.io/disruptor/
一些专家甚至处于无奈而选择完全覆盖 Java 的内存管理机制,由自己来管理内存分配,这虽然解决了问题,但也带来了更多的复杂性和风险。
因此,我们需要考虑使用其他 JVM,于是我们决定尝试 Azul Zing JVM。
很快,我们就能够在几乎无停顿的情况下实现很高的吞吐量。
总结
这个月马上就又要过去了,还在找工作的小伙伴要做好准备了,小编整理了大厂java程序员面试涉及到的绝大部分面试题及答案,希望能帮助到大家
net/forums/4f45ff00ff254613a03fab5e56a57acb)收录**