个人中心 - 腾讯云开发者社区-腾讯云

开发者社区

文档建议反馈控制台

文章/答案/技术大牛

发布

个人中心"kafka" 的搜索结果

来自专栏

Kafka重平衡机制

重平衡跟消费组紧密相关，它保证了消费组成员分配分区可以做到公平分配，也是消费组模型的实现，消费组模型如下：

1.5K4 0

来自专栏

图解：Kafka 水印备份机制

高可用是很多分布式系统中必备的特征之一，Kafka 日志的高可用是通过基于 leader-follower 的多副本同步实现的，每个分区下有多个副本，其中只有一个是 leader 副本，提供发送和消费消息，其余都是 follower 副本，不断地发送 fetch 请求给 leader 副本以同步消息，如果 leader 在整个集群运行过程中不发生故障，follower 副本不会起到任何作用，问题就在于任何系统都不能保证其稳定运行，当 leader 副本所在的 broker 崩溃之后，其中一个 follower 副本就会成为该分区下新的 leader 副本，那么问题来了，在选为新的 leader 副本时，会导致消息丢失或者离散吗？Kafka 是如何解决 leader 副本变更时消息不会出错？以及 leader 与 follower 副本之间的数据同步是如何进行的？带着这几个问题，我们接着往下看，一起揭开 Kafka 水印备份的神秘面纱。

1.1K1 0

来自专栏

Kafka 删除主题流程分析

之前有个 Kafka 集群的每个节点的挂载磁盘多达 20+ 个，平均每个磁盘约 1T，每个节点的分区日志被平均分配到这些磁盘中，但由于每个分区的数据不一致，而集群节点 log.retention.bytes 这个参数的默认值是 -1，也就是没有任何限制，因此 Kafka 的日志删除日志依赖 log.retention.hours 参数来删除，因此会出现日志未过期，磁盘写满的情况。

1.5K2 0

来自专栏

Kafka 常用运维脚本

集群管理（1）启动 broker $ bin/kafka-server-start.sh daemon <path>/server.properties （2）关闭 broker $ bin/kafka-server-stop.sh topic 管理 kafka-topics.sh 脚本 # 创建主题 $ bin/kafka-topics.sh --create --zookeeper localhost:2181 --partitions 64 --replication-factor 3 --topi

1.6K2 0

来自专栏

Kafka ISR 副本同步机制

ISR（in-sync replica）就是 Kafka 为某个分区维护的一组同步集合，即每个分区都有自己的一个 ISR 集合，处于 ISR 集合中的副本，意味着 follower 副本与 leader 副本保持同步状态，只有处于 ISR 集合中的副本才有资格被选举为 leader。一条 Kafka 消息，只有被 ISR 中的副本都接收到，才被视为“已同步”状态。这跟 zk 的同步机制不一样，zk 只需要超过半数节点写入，就可被视为已写入成功。

4K1 0

来自专栏

Kafka 消息存储与索引设计

消息中间件的性能好坏，它的消息存储的机制是衡量该性能的最重要指标之一，而 Kafka 具有高性能、高吞吐、低延时的特点，动不动可以上到几十上百万 TPS，离不开它优秀的消息存储设计。下面我按照自己的理解为大家讲解 Kafka 消息存储设计的那些事。

1.7K2 0

来自专栏

Kafka 分区重分配源码分析

上一篇跟大家描述了 Kafka 集群扩容的方案与过程，这次就跟大家详细描述 Kafka 分区重分配的实现细节。

1.1K2 0

来自专栏

Kafka 独立消费者

以前我们讨论的消费组，都是 group 的形式，group 可以自动地帮助消费者分配分区，且在发生异常时，还能自定地进行重平衡（Rebalance）。正常来说，group 帮助用户实现自动监听分区消费，但是在用户需要指定分区进行精确消费的场景下，由于 group 的重平衡机制，会打破这种消费方式，这不前段时间某项目就有个需求是这样的：

1.7K3 1

来自专栏

一次 kafka 消息堆积问题排查

项目中某 kafka 消息组消费特别慢，有时候在 kafka-manager 控制台看到有些消费者已被踢出消费组。

5.9K2 0

来自专栏

聊聊 page cache 与 Kafka 之间的事儿

关于Kafka的一个灵魂拷问：它为什么这么快？或者说，为什么它能做到如此大的吞吐量和如此低的延迟？

1K3 0

来自专栏

记一次 Kafka 集群线上扩容

前段时间收到某个 Kafka 集群的生产客户端反馈发送消息耗时很高，于是花了一段时间去排查这个问题，最后该集群进行扩容，由于某些主题的当前数据量实在太大，在对这些主题迁移过程中花费了很长一段时间，不过这个过程还算顺利，因为在迁移过程中也做足了各方面的调研，包括分区重平衡过程中对客户端的影响，以及对整个集群的性能影响等，特此将这个过程总结一下，也为双十一打了一剂强心剂。

1.8K1 0

来自专栏

Kafka分区副本与RocketMQ队列的区别

最近在学习 Kafka，发现其核心概念与 RocketMQ 还是存在一定的差别，下面我来说下 Kafka 分区与 RocketMQ 队列之间的区别。

4.1K2 0

来自专栏

Kafka 集群突破百万 partition 的技术探索

导语：本篇文章主要从元数据，controller 逻辑等方面介绍了如何解决支撑百万 partition 的问题，运营大规模集群其实还涉及到磁盘故障、冷读、数据均衡等数据方面的问题，监控和报警服务同样非常的重要。

7113 0

来自专栏

Kafka Producer 异步发送消息居然也会阻塞？

Kafka 一直以来都以高吞吐量的特性而家喻户晓，就在上周，在一个性能监控项目中，需要使用到 Kafka 传输海量消息，在这过程中遇到了一个 Kafka Producer 异步发送消息会被阻塞的问题，导致生产端发送耗时很大。

4.5K6 1

来自专栏

一文看懂 Kafka 消息格式的演进

消息引擎最重要的工作就是将生产者生产的消息传输到消费者，消息的格式应该要怎么设计是各大消息引擎框架最核心的问题，消息格式决定了消息引擎的性能与效率，Kafka 在过去的多个版本迭代中，衍生了 3 个版本的消息格式，每个版本的消息格式之间究竟有哪些差异，它们之间的升级解决了什么样的问题呢？下面我就对 Kafka 的消息格式进行深度剖析。

1.9K1 0

来自专栏

记一次 Kafka 重启失败问题排查

在 2 月10 号下午大概 1 点半左右，收到用户方反馈，发现日志 kafka 集群 A 主题的 34 分区选举不了 leader，导致某些消息发送到该分区时，会报如下 no leader 的错误信息：

2.7K2 0

来自专栏

记一次 Kafka Producer 性能调优实战

最近，遇到某个集群的生产端发送延迟特别高，而且吞吐量上不去，检查集群负载却很低，且集群机器配置非常好，网络带宽也很大，于是使用 Kafka 压测脚本进行了压测。

4.9K3 1

来自专栏

关于 Kafka 的一些面试题目

上周客串了一下面试官，在这里就简单记录一下期间我问到的一些关于 Kafka 的面试题目，这些都是我平时在学习 Kafka 的一些总结要点。

1.1K3 0

来自专栏

Kafka消息体大小设置的一些细节

还记得前几天有个小伙伴跟我反馈发送消息时提示请求数据过大的异常吗？经过调整 max.request.size 的大小之后，又报了了如下异常：

6.2K3 0

来自专栏

彻底搞懂 Kafka 消息大小相关参数设置的规则

根据 Kafka 消息大小规则设定，生产端自行将 max.request.size 调整为 4M 大小，Kafka 集群为该主题设置主题级别参数 max.message.bytes 的大小为 4M。

14.3K6 5