fenglei0415的博客

端到端Exactly Once的含义就是：Source的每条数据会被处理有且仅有一次，并且输出到Sink中的结果不重不丢。Flink和Spark structure streaming能否做到端到端的exactly once？是可以的。由于原理类似，接下来拿spark举例分析一下。kafka有关详细内容请看：KIP-98 - Exactly Once Delivery and Transactional Messaging - Apache Kafka - Apache Software Fou

最近看了下kafka2.7.0的源码，相对2.0.0已经有挺多细节发生了变动。印象最深有两点：日志索引项的二分查找做了优化。原理不复杂，但是却挺高级。问题是原版的二分查找是没有考虑到缓存的，一旦生成了新的索引项会强行变更查找路径。新版的算法考虑到了热区和冷区。 Rebalance的时候，添加了静态consumer，就不必所有consumer全部参与重分配了，这也是在性能上有很大提升。kafka2.0.0二分源码如下：kafka-2.7.0二分源码如下：...

关于算法，我一直的想法是，我们平时太注重算法本身，或者是为了面试学算法，却忽略了它们在实际场景中的应用。比如说，我们学习了太多的排序算法，但是，对于普通的应用开发人员来说，亲自使用这些算法去设计编程任务的机会实在太少了。说起数组排序，第一时间可能只记得Collections.sort 方法了，但它底层应用了什么排序算法，其实也需要研究。难得的是，在阅读Kafka源码的过程中，遇到了一些算法设计，看完有种醍醐灌顶的感觉。举两个感触比较深的例子。一. 二分查找Kafka 中直接接触索引或索引文件..

Log 的常见操作分为 4 大部分：高水位管理操作：高水位的概念在 Kafka 中举足轻重，对它的管理，是 Log 最重要的功能之一。 日志段管理：Log 是日志段的容器。高效组织与管理其下辖的所有日志段对象，是源码的核心。 关键位移值管理：日志定义了很多重要的位移值，比如 Log Start Offset 和 LEO 等。确保这些位移值的正确性，是构建消息引擎一致性的基础。 读写操作：所谓的操作日志，大体上就是指读写日志。读写操作是kafka高吞吐量的基础。高水位管理操作一. 高水位定义

日志（Log）是日志段（Log Segment）的容器，里面定义了很多管理日志段的操作。Log 源码结构Log 源码位于 Kafka core 工程的 log 源码包下，文件名是 Log.scalaLog Class & ObjectLog Obj：object Log { val LogFileSuffix = ".log" val IndexFileSuffix = ".index" val TimeIndexFileSuffix = ".timeindex

kafka的高吞吐量和持久性是一大亮点，内部的日志操作是如何呢，研究明白了一定豁然开朗，至少我有种恍然大明白的感觉。kafka的日志结构Kafka 日志对象由多个日志段对象组成，而每个日志段对象会在磁盘上创建一组文件。包括消息日志文件（.log）、位移索引文件（.index）、时间戳索引文件（.timeindex）以及已中止事务的索引文件（.txnindex）。当然，如果你没有使用 Kafka 事务，已中止事务的索引文件是不会被创建出来的。图中的一串数字 0 是该日志段的起始位移值（Base

承接上一篇，请求的接收与分发(https://blog.youkuaiyun.com/fenglei0415/article/details/106172921)，接下来应该是请求队列的通道(https://blog.youkuaiyun.com/fenglei0415/article/details/105960812)。本篇是I/O的线程逻辑。Broker端参数 num.io.threads 参数表示的就是 I/O 线程池的大小。所谓的 I/O 线程池，即 KafkaRequestHandlerPool，也称请求处理线程池

承接上一篇(https://blog.youkuaiyun.com/fenglei0415/article/details/106162288)二. 请求的接收以及分发主要分析两个类，实现网络通信的关键部件。分别是Acceptor 类和Processor 类。先介绍下SocketServer组件下的类：AbstractServerThread 类：这是 Acceptor 线程和 Processor 线程的抽象基类，定义了这两个线程的公有方法，如 shutdown（关闭线程）等。 Acceptor 线程

kafka的源码路上一直都是个小学生，如有发现错误，请多指正，不胜感激。总结了一张kafka网络通信层架构，如图：整张图大概划分5部分，分别是：客户端发送请求、请求的接收以及分发、请求通道的处理、I/O线程执行、实际处理请求并处理响应...

最近一直研究kafka源码，想着有必要记录一下。不管研究是否到位，也算是一个里程碑吧。当我们说到 Kafka 服务器端，也就是 Broker 的时候，往往会说它承担着消息持久化的功能，但本质上，它其实就是一个不断接收外部请求、处理请求，然后发送处理结果的 Java 进程 (因为scala 代码被编译之后生成.class 文件，它和 Java 代码被编译后的效果是一样的)。高效地保存排队中的...