7 天前 / yes的练级攻略
点击上方「yes 的练级攻略」加个「星标」，最新文章极速到达大家好，我是 yes。 最近看 Kafka 看到了时间轮算法，记得以前看 Netty 也看到过这玩意，没太过关注。今天就来看看时间轮到底是什么东西。 为什么要用时间轮算法来实现延迟操作？ 延时操作 Java 不是提供了 Timer 么？ 还有 DelayQueue 配合线程池或者 ScheduledThreadPool 不香吗？ 我们先来简单看看 Timer、DelayQueue 和 ScheduledThreadPool 的相关实现，看看它们是如何实现延时任务的，源码之下无秘密。再来剖析下为何 Netty 和 Kafka 特意实现了时间轮来处理延迟任务。
7 天前 / 搬运工来架构
点击上方蓝色字关注我们~ 我们经常会面临这样的问题，在确定某个 topic 下应该设置多少分区数，有时并不知道应该如何设置，如何评估等。或者别人问你当前 kafka 集群中，具体的业务 topic 中分区数是多少，是如何知道需要多少分区或怎么选择比较适合的分区数。 1 结合业务场景和非业务条件 那么我们应该如何选择合适的分区数呢？ 具体的业务具体分析。 但是前期我们可以根据这些条件：实际业务场景（消息总量，消息生产或消费频率，要求的吞吐量等）、软件条件、硬件条件、负载情况等，进行大致的评估我们可以设置 topic 多少分区数。
14 天前 / yes的练级攻略
点击上方「yes 的练级攻略」加个「星标」，最新文章极速到达 大家好，我是 yes。 我们都知道 RocketMQ 和 Kafka 消息都是存在磁盘中的，那为什么消息存磁盘读写还可以这么快？有没有做了什么优化？都是存磁盘它们两者的实现之间有什么区别么？各自有什么优缺点？ 今天我们就来一探究竟。 存储介质 - 磁盘一般而言消息中间件的消息都存储在本地文件中，因为从效率来看直接放本地文件是最快的，并且稳定性最高。毕竟要是放类似数据库等第三方存储中的话，就多一个依赖少一份安全，并且还有网络的开销。
28 天前 / yes的练级攻略
大家好，我是 yes。 这是我的第三篇 Kafka 源码分析文章，前两篇讲了日志段的读写和二分算法在 kafka 索引上的应用 今天来讲讲 Kafka Broker 端处理请求的全流程，剖析下底层的网络通信是如何实现的、Reactor 在 kafka 上的应用。 再说说社区为何在 2.3 版本将请求类型划分成两大类，又是如何实现两类请求处理的优先级。 叨叨不过在进入今天主题之前我想先叨叨几句，就源码这个事儿，不同人有不同的看法。 有些人听到源码这两个词就被吓到了，这么多代码怎么看。奔进去就像无头苍蝇，一路断点跟下来，跳来跳去，算了拜拜了您嘞。
37 天前 / 猿天地
一次机房停电引发的思考今天早上到公司的时候，接到开发反馈 DEV 环境所有接口都卡，耗时都在一分钟以上，严重影响开发正常工作，然后通过网关的日志定位到原因是因为 kafka 集群不可用（总共 3 个 broker，前一天晚上机房停电导致 leader 节点挂了），导致网关的反爬过滤器里面发送 kafka 消息的代码 kafkaTemplat.send 阻塞了 60s，当时在想这个 send 方法不是异步的吗，为什么会阻塞 60s？于是查阅了一些资料，大致搞清楚了原因，这里稍作整理，分享给可能踩坑或者以及踩过坑的同学。
48 天前 / php-v
在一个关于消息队列的公众号里，ACK 指的是什么呢？ 对于消息队列而言就是管理消费状态：哪些消息被消费了，哪些还没有消费，已经消费的消息我就不要再消费了，没有消费的消息别给我漏掉了。 比如消息生产端发送了 20 条消息，我收到了 10 条，处理完成了其中 7 条，其中 5 条处理成功了，2 条处理失败了，还有 3 条还没开始处理，另外还有 10 条我还没收到。那么处理成功的 5 条我不要再处理了，处理失败的 2 条是什么策略？这些都是 ACK 管理所需要关心的内容。
76 天前 / 一条老狗
点击上方蓝字“极客运维”一起运筹帷幄 上篇文章我们了解到，如果一个 topic 分区越多，理论上整个集群所能达到的吞吐量就越大。那么，分区数越多就越好吗？显然不是。今天我们来聊下 kafka 在分区数过多的情况下，会带来哪些弊端。 内存开销客户端 producer 有个参数 batch.size 默认为 16KB。它会为每个分区缓存消息，一旦批次数满了后，将消息批量发出。一般来说，这个设计是用于提升吞吐性能的。但是由于这个参数是 partition 级别的，如果分区数越多，这部分缓存所需的内存占用也会越多。
77 天前 / sjf0115
女主宣言 Kafka 作为一个支持实时处理大量请求的分布式流处理平台，需要一个设计良好的定时器来处理异步任务。本文作者将基于 Kafka 1.1.0 版本的源码来介绍 Kafka 中定时器的基础数据结构——时间轮的原理和实现。 PS：丰富的一线技术、多元化的表现形式，尽在“360 云计算”，点关注哦！ 1 简单时间轮 简单时间轮是时间任务桶的循环链表，又被称为桶（bucket）。令 u 为时间单元大小，一个大小为 n 的时间轮有 n 个桶，能够持有 n * u 个定时任务，每个任务的过期时间会落在一个时间间隔内。
82 天前 / 过往记忆大数据
目前，Apache Kafka 使用 Apache ZooKeeper 来存储它的元数据，比如分区的位置和主题的配置等数据就是存储在 ZooKeeper 集群中。在 2019 年社区提出了一个计划 [1]，以打破这种依赖关系，并将元数据管理引入 Kafka 本身。 所以 Apache Kafka 为什么要移除 Zookeeper 的依赖？Zookeeper 有什么问题？实际上，问题不在于 ZooKeeper 本身，而在于外部元数据管理的概念。 拥有两个系统会导致大量的重复。毕竟，Kafka 是一个分布式的发布 - 订阅消息系统，而 ZooKeeper 其实也是一个分布式日志系统，其上有一个文件系统 API。
82 天前 / 一条老狗
点击上方蓝字“极客运维”一起运筹帷幄 分区 (partition)概念要讲 kafka 分区数和吞吐量的关系，首先得理解什么是分区 (partition)。 Partition 是作用于具体的 Topic 而已的，而不是一个独立的概念。Partition 能水平扩展客户端的读写性能，是高吞吐量的保障。通俗的讲，Partition 就是一块保存具体数据的空间，本质就是磁盘上存放数据的文件夹，所以 Partition 是不能跨 Broker 存在的，也不能在同一个 Broker 上跨磁盘。对于一个 Topic，可以根据需要设定 Partition 的个数。
85 天前 / 大数据技术架构
前言在前面文章《Kafka 精进 | 一文读懂 Producer 消息发送机制》中，我们从 Kafka 消息结构、序列化器、分区器及消息缓冲池等方面介绍了 Producer 端的原理，回顾示意图如下： 实际使用中，Producer 端既要保证吞吐量，又要确保无消息丢失，一些核心参数的配置显得至关重要。本文我们就来看看生产端都有哪些重要的参数。生产端核心参数 1. acks 参数说明：这是一个非常重要的参数，表示指定分区中成功写入消息的副本数量，这是 Kafka 生产端消息的持久性（durability）保证。
91 天前 / 一条老狗
点击上方蓝字“极客运维”一起运筹帷幄 生产环境的 kafka 集群扩容，是一个比较常见的需求和操作。然而 kafka 在新增节点后并不会像 elasticsearch 那样感知到新节点加入后，自动将数据 reblance 到整个新集群中，因此这个过程需要我们手动分配。 分区重分配方案扩容后的数据均衡，其本质就是对 topic 进行分区重分配，数据迁移的过程。在执行分区重分配的过程中，对集群的影响主要有两点： 分区重分配主要是对 topic 数据进行 Broker 间的迁移，因此会占用集群的带宽资源；分区重分配会改变分区 Leader 所在的 Broker，因此会影响客户端。
114 天前 / 大数据技术架构
前面我们总结了 broker 端的核心参数，一些服务端原理细节后面文章再聊。本文我们重点讨论 Producer 端的消息发送机制，希望通过本文我们能整体掌握 Producer 端的原理。 1、Producer 架构一图胜千言，这里笔者画了一张 Producer 端消息发送的基本流程，如下图： 总的来说，Kafka 生产端发送数据过程涉及到序列化器 Serializer、分区器 Partitioner，消息缓存池 Accumulator，还可能会涉及到拦截器 Interceptor（这部分暂不做介绍）。由于篇幅有限这里尽量做到言简意赅。
126 天前 / ThoughtWorks
Apache Kafka 内核深度剖析 2020 年 2 月 18 日 by 白发川 Leave a Comment 摘要 目前来说市面上可以选择的消息队列非常多，像 activemq，rabbitmq，zeromq 已经被大多数人耳熟能详，特别像 activemq 早期应用在企业中的总线通信，基本作为企业级 IT 设施解决方案中不可或缺的一部分。目前来说 Kafka 已经非常稳定，并且逐步应用更加广泛，已经算不得新生事物，但是不可否认 Kafka 一枝独秀如同雨后春笋，非常耀眼，今天我们仔细分解一下 Kafka，了解一下它的内幕。以下的内容版本基于当前最新的 Kafka 稳定版本 2.4.0。
128 天前 / sjf0115
摘要：本文基于 Flink 1.9.0 和 Kafka 2.3 版本，对 Flink Kafka source 和 sink 端的源码进行解析，主要内容分为以下两部分： 1.Flink-kafka-source 源码解析 流程概述 非 checkpoint 模式 offset 的提交 checkpoint 模式下 offset 的提交 指定 offset 消费 2.Flink-kafka-sink 源码解析 初始化 Task 运行 小结 Tips：Flink 中文社区征稿啦，感兴趣的同学可点击「阅读原文」了解详情～ 1.Flink-kafka-source源码解析 流程概述 一般在 Flink 中创建 kafka source 的代码如下： StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecution...