Kafka-日志存储

最新推荐文章于 2025-12-17 13:48:48 发布
原创 最新推荐文章于 2025-12-17 13:48:48 发布 · 224 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#kafka

本文详细介绍了Kafka的日志管理机制，包括偏移量索引和时间戳索引的构建，如何通过二分查找快速定位日志条目。日志分段后使用ConcurrentSkipListMap保存，确保根据偏移量和时间戳高效检索。同时，讨论了日志清理策略，如按条件删除和消息Key的整合。此外，还分析了Kafka实现高吞吐量存储的原因，如磁盘顺序写入、页缓存以及零拷贝技术的应用。

文章目录

日志索引

  • 索引文件以稀疏索引的方式构造消息的索引，每当写入一定量，偏移量索引文件和时间戳索引文件分别增加一个偏移量索引项和时间戳索引项。
  • 俩个索引文件采用二分查找快速定位

偏移量索引

  • 日志分段后，为每个日志对象使用ConcurrentSkipListMap来保存各个日志分段，每个日志分段的baseOffset作为key，这样可以根据指定偏移量快速定位到消息所在的日志分段

时间戳索引

  • 新追加的时间戳索引项中的timestamp必须大于之前追加的索引中的timestamp
  • 日志分段处理同偏移量索引
  • 俩个文件增加索引是同时进行的，但位置可能不同

日志清理

日志删除：按照一定条件进行删除

日志压缩：对消息的Key进行整合

日志存储

  • Kafka依赖于文件系统（磁盘）来进行存储

高吞吐量的存储层次原因

  • 磁盘的顺序写入
  • 采用页缓存机制
    • 由于进程内部的内存消耗，以及重启之后内存的重建，GC问题
  • 零拷贝
    • 依赖于底层的sendFile方法
    • 请求内核把磁盘中的数据传输给Socket
    • 省去Socket Buffer过程
    • 经历过2次磁盘复制，上下文切换2次
Kafka-Eagle、Kafka-UI的安装及使用详细教程
weixin_64860388的博客
11-12 3274
Kafka-Eagle 框架可以监控 Kafka 集群的整体运行情况，在生产环境中经常使用。在生产过程中，想创建topic、查看所有topic、想查看某个topic 想查看分区等，都需要写命令，能不能有一个图形化的界面，让我们操作呢？
Apisix插件之kafka-logger
he20021221的博客
09-04 945
APISIX的kafka-logger插件可将网关日志异步发送到Kafka，支持自定义日志格式、批量发送和失败重试。核心参数包括Kafka集群地址(brokers)、主题(topic)、批量大小(batch_max_size)等。该插件通过缓存日志并批量发送到指定topic，配合重试机制确保可靠性，适用于分布式日志收集、实时监控和业务分析等场景。注意需合理配置生产者类型(producer_type)和确认机制(required_acks)以平衡性能与可靠性。
深入Kafka - 日志存储
u010059975的博客
02-24 643
Kafka中的消息是以主题为基本单位进行归类的，各个主题在逻辑上相互独立。每个主题又可以分为一个或多个分区。 不考虑多副本的情况，每个分区对应一个日志（Log），每个日志包含多个日志分段（LogSegment），对应到物理存储，可以理解为Log对应日志一个目录，每个LogSegment对应一个日志文件和两个索引文件，以及可能的其他可能文件（比如事务索引文件）。 举例说明，假设有名为topic-lo...
kafka-日志清理
m0_69378371的博客
01-31 637
不同的系统和平台，如 Kafka、Elasticsearch 和 Linux 系统，都提供了相应的日志清理机制，帮助管理员高效管理日志数据。• 保留时间：这种方式是最常见的日志清理策略，通常通过设置日志的 保留时间（例如 7 天、30 天、1 年等）来决定何时删除日志文件。在日志清理时，Kafka 会确保所有副本的日志一致性，避免在清理过程中丢失数据。• Kafka 可以设置日志分区的最大大小，当某个分区日志的大小达到配置的上限时，Kafka 会自动清理最旧的日志数据，避免存储空间被占满。
kafka-日志存储
小城我家
11-14 2386
日志存储 Kafka 消息是以主题为单位进行归类，各个主题之间是彼此独立的，互不影响。 每个主题又可以分为一个或多个分区。 每个分区各自存在一个记录消息数据的日志文件 创建了一个 tp_demo_01 主题，其存在6个 Parition，对应的每个Parition下存在一个 [Topic-Parition] 命名的消息日志文件。在理想情况下，数据流量分摊到各个 Parition 中，实现了负载均衡的效果。在分区日志文件中，你会发现很多类型的文件，比如： index、.timestamp、.log、.sna
Kafka-服务端-日志存储
andy的博客
01-22 1581
Kafka中存储的一般都是海量消息数据，为了避免日志文件太大，Log并不是直接对应于磁盘上的一个日志文件，而是对应磁盘上的一个目录，这个目录的命名规则是<topic_name>_≤partition_id>,Log与分区之间的关系是一一对应的，对应分区中的全部消息都存储在此目录下的日志文件中。在重建索引文件过程中，如果遇到了压缩消息需要进行解压，主要原因是因为索引项中保存的相对offset是第一条消息的offset,而外层消息的offset是压缩消息集合中的最后一条消息的offset。
kafka专题笔记 - 日志存储
qq_39679639的博客
10-24 3028
文件目录布局 下面以本地kafka日志文件夹为例，介绍kafka文件目录布局。 kafka文件的存储目录，可以通过配置服务log.dirs确定，我本地环境使用默认的地址，log.dirs=/usr/local/var/lib/kafka-logs，进入文件夹，可以看到目前的文件内容如下: ➜ kafka-logs ls __consumer_offsets-0 __consumer_offsets-22 __consumer_offsets-36
6.kafka--日志存储
qq_24223159的博客
01-30 1272
无
【基础】Kafka -- 日志存储
情绪瓜皮皮丶的学习之路
04-25 3069
整理总结了 Kafka 日志相关的基础知识
kafka-dump-log.sh
qq_25624635的博客
01-08 679
是 Kafka 提供的一个脚本工具，用于解析 Kafka 日志文件（即 Broker 上存储的分区日志文件）。它通常用于调试或分析 Kafka 的内部数据。
kafka-2.12-3.4.0.tgz
02-10
- 配置server.properties文件，设置broker的ID、端口、日志存储路径等。 - 启动Zookeeper服务，然后启动Kafka Broker。 - 创建主题，设置主题的分区数和副本数。 5. **使用Kafka**： - 使用Kafka的命令行工具...
精选资源
kafka-2.12-2.8.2
06-14
1. 日志收集：Kafka常用于收集各种应用的日志数据，提供统一的接口和存储。 2. 数据整合：在微服务架构中，Kafka作为消息中间件，连接各个服务进行数据交换。 3. 实时分析：结合流处理引擎（如Spark Streaming或...
精选资源
KAFKA-3.1.1-1.3.1.1.p0.2-el7.parcel
08-15
它被广泛用于实时数据管道和流应用，允许应用程序实时处理和存储大量数据。 描述中的“KAFKA-3.1.1-1.3.1.1.p0.2-el7”进一步确认了这是Kafka的一个具体构建，适用于el7（RHEL 7）。这个描述没有提供额外的信息，但...
精选资源
kafka-2.12-3.6.1.tgz
12-19
Kafka，作为一款高效、可扩展且持久化的分布式消息中间件，被广泛应用于大数据实时处理、日志收集和流处理等场景。本文将详细介绍如何在Linux环境下部署并使用Kafka 2.12-3.6.1版本。 一、系统要求 在开始安装前，...
十三、Kafka基础环境实战
pale_moonlight的博客
12-16 879
（启动Hadoop：start-all.sh 启动Hadoop：zkServer.sh start）此次实验有些许复杂，需要细心操作。复制一个会话（第三个）
kafka和其他消息队列的区别
qq_52531977的博客
12-13 882
摘要： Kafka与其他消息队列（RabbitMQ、RocketMQ等）的核心差异源于设计目标不同。Kafka定位为高吞吐分布式日志系统，侧重持久化存储与批量处理，通过分区扩展、顺序写磁盘和零拷贝实现百万级TPS，适配大数据流处理；而RabbitMQ等侧重即时消息投递，提供灵活路由、低延迟（微秒级）和事务支持，适合业务解耦。RocketMQ则平衡吞吐与可靠性，支持金融级场景。选型需权衡吞吐、延迟、功能（如事务/回溯）及生态适配（如Kafka整合Flink）。关键区别在于Kafka是“存储优先”，其他MQ是“
分布式消息队列kafka【五】—— kafka海量日志收集实战
qq_46601365的博客
12-16 850
摘要 本文介绍了基于Kafka的海量日志收集实战方案，采用ELK技术栈架构（Filebeat+Kafka+Logstash+ES+Kibana）。重点分析了为何选用Kafka作为缓冲层缓解ES压力，以及Log4j2相比Logback的性能优势（18倍提升）。详细阐述了日志分级策略（app.log/error.log分离）、MDC线程变量等日志处理技术，并深入解析Filebeat轻量级采集原理及其与Logstash的协作关系。该架构通过多组件协同工作，实现了高性能、低延迟的海量日志收集、处理和分析全流程。
Kafka详解
最新发布
sk13587280072的博客
12-17 565
3.1 Kafka定义Kafka是一个分布式的基于发布/订阅模式的消息队列（MQ，Message Queue），主要应用于大数据实时处理领域。3.2 Kafka简介Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于Zookeeper协调的分布式消息中间件系统。
Kafka 客户端 Offset Explore 配置
u011962508的博客
12-13 360
Offset Explore 配置
kafka-manager出现Yikes! Ask timed out on [ActorSelection[Anchor(akka://kafka-manager-system/), Path(/user/kafka-manager/kafka-manager-cluster/kafka-state)]] after [2000 ms]. Message of type [kafka.manager.model.ActorModel$KSGetBrokers$] was sent by [Actor[akka://kafka-manager-system/user/kafka-manager/kafka-manager-cluster#1227071506]]. A typical reason for `AskTimeoutException` is that the recipient actor didn't send a reply. 什么原因导致？
09-25
<think> 嗯，用户这次在问kafka-manager出现Akka通信超时的具体原因分析。从用户提供的三个引用来看，问题核心在于Akka框架的RPC调用超时，但具体诱因可能有多个维度需要排查。 用户引用的报错信息特别详细，连超时时间和消息类型都标注出来了：KSGetBrokers请求在2000ms后超时，发送方是kafka-manager-cluster组件。这种细节对诊断很有帮助，说明用户具备一定的技术观察力。 先拆解可能原因：引用[1]提到经典的两大类情况——要么是消息根本没送达（网络/序列化问题），要么是接收方处理太慢（性能瓶颈）。但引用[3]又补充了配置错误的可能性，尤其是ZK配置这种基础项。有趣的是用户特意强调"昨天正常今天报错"，这直接排除了长期存在的配置错误，把范围缩小到动态变化因素。 注意到用户提到流量仅1000条/min，基本可以排除负载压力。那么重点考虑：临时网络抖动（需要查交换机日志）、ZK连接异常（确认session timeout配置）、或是kafka-manager自身GC停顿（查JVM监控）。引用[2]中Flink的案例其实给了重要暗示——Akka超时参数可能不适应真实网络环境，用户当前2000ms的设置显然偏紧。 特别要警惕的是kafka-state这个接收方组件。从路径看它属于集群状态管理模块，如果集群有分区异常或ISR同步延迟，可能会导致它阻塞在某个操作上无法及时响应RPC。这需要结合kafka-server.log交叉验证。 最后想到个隐蔽点：kafka-manager版本是否与Kafka集群版本匹配？某些老版本manager访问新协议集群时，会因解析元数据耗时增加而触发超时。这个在社区issue里常被忽视。 </think> 根据提供的引用信息和Akka框架特性，kafka-manager出现`Ask timed out on [ActorSelection...]`错误的核心原因和排查方向如下： --- ### **根本原因** Akka框架的**RPC异步通信超时**，具体表现为： 1. **接收方Actor未在指定时间内响应**（此处超时阈值为2000ms） 2. **消息类型**：`kafka.manager.model.ActorModel$KSGetBrokers$`（获取Kafka Broker信息的请求） 3. **通信路径**：`kafka-manager-cluster`组件尝试访问`kafka-state`服务超时[^1][^3] --- ### **具体诱因分析** #### 1. **资源瓶颈或性能问题**（可能性较高） - **Kafka集群负载过高**：Broker节点CPU/IO满载，无法及时响应元数据请求 - **ZK压力过大**：Kafka依赖ZooKeeper存储元数据，若ZK集群延迟高会导致超时 - **kafka-manager资源不足**：JVM内存不足或GC停顿导致处理延迟（需检查Heap使用率） #### 2. **网络或配置问题** - **网络抖动/分区**：节点间网络延迟超过阈值（2000ms） - **ZK连接异常**： - ZooKeeper地址错误（如格式应为`ip1:port1,ip2:port2`）[^3] - ZK会话超时（`zookeeper.session.timeout.ms`设置过短） - **防火墙拦截**：阻断kafka-manager与Broker/ZK的通信端口 #### 3. **Akka参数配置不当**（关键因素） - **超时阈值过低**：默认`akka.ask.timeout=2000ms`无法满足当前环境需求 （尤其跨机房或高负载场景需增大阈值）[^2] - **线程阻塞**：同步操作阻塞Akka线程池，导致消息积压 #### 4. **组件状态异常** - **kafka-state服务宕机**：目标Actor未启动或崩溃 - **版本兼容性问题**：kafka-manager与Kafka集群版本不匹配 --- ### **排查与解决步骤** #### ✅ **第一阶段：基础检查** 1. **验证ZK连接** ```bash telnet zk_host1 2181 # 测试ZK端口连通性 echo stat | nc zk_host1 2181 # 检查ZK状态 ``` 2. **检查kafka-manager日志** 搜索`ERROR`/`WARN`日志，确认是否有堆栈错误（如序列化失败、认证错误等） #### ✅ **第二阶段：资源与网络诊断** 1. **监控关键指标** - Kafka Broker：`CPU利用率`、`NetworkHandlerAvgIdlePercent` - ZK：`Watcher数量`、`Znode数量`、`Latency` - kafka-manager JVM：`GC时间`、`堆内存使用率` 2. **网络测试** ```bash mtr -r -c 60 Broker_IP # 持续检测网络丢包率与延迟 ``` #### ✅ **第三阶段：参数调优** 1. **增大Akka超时阈值** 在`kafka-manager`配置中增加： ```conf akka.ask.timeout = 10s # 建议先调整为10秒测试 ``` 2. **调整ZK超时参数**（参考值） ```conf kafka-manager.zkhosts="zk_host:2181" kafka-manager.zkhosts.timeout=30000 # ZK会话超时设为30秒 ``` #### ⚠️ **终极方案** 若上述无效且日志无明确错误，尝试**重启kafka-manager**以恢复Actor状态[^3]： ```bash sudo systemctl restart kafka-manager ``` --- ### **典型解决方案优先级** ```mermaid graph LR A[发现超时] --> B{检查日志} B -->|有明确错误| C[针对性修复] B -->|无明确错误| D[增大akka.ask.timeout] D --> E[测试稳定性] E -->|仍超时| F[检查ZK/Broker状态] F -->|资源过载| G[扩容集群] F -->|网络问题| H[修复网络] ``` --- **
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值