随笔分类 - 【101】Kafka
摘要：早期的消息队列，就是按照“队列”的数据结构来设计的 发布 - 订阅模型 在发布 - 订阅模型中，消息的发送方称为发布者（Publisher），消息的接收方称为订阅者（Subscriber），服务端存放消息的容器称为主题（Topic） 发布者将消息发送到主题中，订阅者在接收消息之前需要先“订阅主题”
阅读全文
摘要：消费者组的重平衡流程 它的作用是让组内所有的消费者实例就消费哪些主题分区达成一致 在 Coordinator 的帮助下完成整个消费者组的分区重分配 重平衡的 3 个触发条件： 1、组成员数量发生变化。 2、订阅主题数量发生变化。 3、订阅主题的分区数发生变化 在实际生产环境中，因命中第 1 个条件而
阅读全文
摘要：无论是 Kafka 客户端还是 Broker 端，它们之间的交互都是通过“请求 / 响应”的方式完成的 Apache Kafka 自己定义了一组请求协议，用于实现各种各样的交互操作 比如常见的 PRODUCE 请求是用于生产消息的，FETCH 请求是用于消费消息的，METADATA 请求是用于请求
阅读全文
摘要：所谓的副本机制（Replication），也可以称之为备份机制，通常是指分布式系统在多台网络互联的机器上保存有相同的数据拷贝 1、提供数据冗余。即使系统部分组件失效，系统依然能够继续运转，因而增加了整体可用性以及数据持久性。 2、提供高伸缩性。支持横向扩展，能够通过增加机器的方式来提升读性能，进而提
阅读全文
摘要：对于 Kafka 消费者来说，最重要的事情就是监控它们的消费进度了，或者说是监控它们消费的滞后程度 这个滞后程度有个专门的名称：消费者 Lag 所谓滞后程度，就是指消费者当前落后于生产者的程度 Lag 的单位是消息数，而且我们一般是在主题这个级别上讨论 Lag 的 但实际上，Kafka 监控 Lag
阅读全文
摘要：何时创建TCP连接？ TCP连接是在调用KafkaConsumer.poll方法时被创造的。再细粒度较小，在poll方法内部有3个时机可以创建TCP连接 1. 发起FindCoordinator请求时。 消费者端有个组件叫协调者（Coordinator） 它驻留在 Broker 端的内存中，负责消费
阅读全文
摘要：Kafka Java Consumer 设计原理 谈到 Java Consumer API，最重要的当属它的入口类 KafkaConsumer 了 KafkaConsumer 就变为了双线程的设计，即用户主线程和心跳线程 所谓用户主线程，就是你启动 Consumer 应用程序 main 方法的那个线
阅读全文
摘要：所谓 CommitFailedException，顾名思义就是 Consumer 客户端在提交位移时出现了错误或异常，而且还是那种不可恢复的严重异常 很多提交位移的 API 方法是支持自动错误重试的，比如我们在上一期中提到的commitSync 方法 异常解释 本次提交位移失败了，原因是消费者组已经
阅读全文
摘要：Consumer 端有个位移的概念 它和消息在分区中的位移不是一回事儿 Consumer 的消费位移，它记录了 Consumer 要消费的下一条消息的位移。这可能和你以前了解的有些出入，不过切记是下一条消息的位移，而不是目前最新消费消息的位移 Consumer 需要向 Kafka 汇报自己的位移数据
阅读全文
摘要：Rebalance 就是让一个 Consumer Group 下所有的 Consumer 实例就如何消费订阅主题的所有分区达成共识的过程 在 Rebalance 过程中，所有 Consumer 实例共同参与，在协调者组件的帮助下，完成订阅主题分区的分配 但是，在整个过程中，所有实例都不能消费任何消息
阅读全文
摘要：__consumer_offsets 在 Kafka 源码中有个更为正式的名字，叫位移主题，即 Offsets Topic。需要注意的是，它有两个下划线哦 将 Consumer 的位移数据作为一条条普通的 Kafka 消息，提交到 __consumer_offsets 中 可以这么说，__consu
阅读全文
摘要：Consumer Group 是 Kafka 提供的可扩展且具有容错性的消费者机制 既然是一个组，那么组内必然可以有多个消费者或消费者实例（Consumer Instance），它们共享一个公共的 ID，这个 ID 被称为 Group ID 组内的所有消费者协调在一起来消费订阅主题（Subscrib
阅读全文
摘要：Kafka 消息交付可靠性保障以及精确处理一次语义的实现 所谓的消息交付可靠性保障，是指 Kafka 对 Producer 和 Consumer 要处理的消息提供什么样的承诺。常见的承诺有以下三种： 最多一次（at most once）：消息可能会丢失，但绝不会被重复发送。 至少一次（at leas
阅读全文
摘要：为何采用 TCP？ Apache Kafka 的所有通信都是基于 TCP 的 而不是基于 HTTP 或其他协议 无论是生产者、消费者，还是 Broker 之间的通信都是如此 人们能够利用 TCP 本身提供的一些高级功能，比如多路复用请求以及同时轮询多个连接的能力 所谓的多路复用请求，即 multip
阅读全文
摘要：什么是拦截器？ 其基本思想就是允许应用程序在不修改逻辑的情况下，动态地实现一组可插拔的事件处理逻辑链 它能够在主业务操作的前后多个时间点上插入对应的“拦截”逻辑 这些功能都是以配置拦截器类的方式动态插入到应用程序中的，故可以快速地切换不同的拦截器而不影响主程序逻辑 Kafka 拦截器借鉴了这样的设计
阅读全文
摘要：那 Kafka 到底在什么情况下才能保证消息不丢失呢？ 一句话概括，Kafka 只对“已提交”的消息（committed message）做有限度的持久化保证 第一个核心要素是“已提交的消息”。 什么是已提交的消息？当 Kafka 的若干个 Broker 成功地接收到一条消息并写入到日志文件后，它们
阅读全文
摘要：压缩（compression） 它秉承了用时间去换空间的经典 trade-off 思想 具体来说就是用 CPU 时间去换磁盘空间或网络 I/O 传输量 希望以较小的 CPU 开销带来更少的磁盘占用或更少的网络 I/O 传输 怎么压缩？ Kafka 的消息层次都分为两层：消息集合（message se
阅读全文
摘要：如何将这么大的数据量均匀地分配到 Kafka 的各个 Broker 上，就成为一个非常重要的问题 为什么分区？ Kafka 有主题（Topic）的概念，它是承载真实数据的逻辑容器 而在主题之下还分为若干个分区，也就是说 Kafka 的消息组织方式实际上是三级结构：主题 - 分区 - 消息 主题下的每
阅读全文
摘要：下半部分主要是 Topic 级别参数、JVM 参数以及操作系统参数的设置 正确设置这些参数是搭建高性能 Kafka 集群的关键因素 Topic 级别参数 如果同时设置了 Topic 级别参数和全局 Broker 参数 答案就是 Topic 级别参数会覆盖全局 Broker 参数的值，而每个 Topi
阅读全文
摘要：很多参数对系统的影响要比从文档上看更加明显 严格来说这些配置并不单单指 Kafka 服务器端的配置，其中既有 Broker 端参数， 也有主题（后面我用我们更熟悉的 Topic 表示）级别的参数、 JVM 端参数 和操作系统级别的参数 Broker 端参数 目前 Kafka Broker 提供了近
阅读全文
浙公网安备 33010602011771号