Kafka 架构、核心机制和场景解读.docxVIP

Kafka 架构、核心机制和场景解读 摘要 Kafka 是一款非常优秀的开源消息引擎，以消息吞吐量高、可动态扩容、可持久化存储、高可用的特性，以及完善的文档和社区支持成为目前最流行的消息队列中间件。 Kafka 的开发社区一直非常活跃，在消息引擎的领域取的不俗成绩之后，不断拓展自己的领域，在基于事件的流处理平台方向一直发力，不断自我更新迭代力图成为这个领域内的事实标准。 Kafka 的消息引擎功能十分强大，但是一直没有停下自我突破的脚步，随着 3.0 版本的中 KRaft 协议的推出，Zookeeper 的退出进程正式启动，Kafka 开始了又一次的自我蜕变。 ZK 的移除是一个非常大胆的举动，因为 ZK 在 Kafka 的集群管理中居于核心的地位，不会轻易取代，那为什么 Kafka 选择了自行实现选举机制的路线？ 此外，虽然 Kafka 具备诸多优秀的特性，这些如今被视为最佳实践的特性也是不断演化而来的，从其不断升级改进的过程中也能间接反映出生产环境所面临的现实问题，那么 Kafka 在实际的生产环境中的表现究竟如何？ 作为业务方，使用 Kafka 作为消息中间件进行业务开发，保证服务平稳运行需要避开哪些雷区？ 这篇文档将从一个比较高的视角，从 Kafka 的设计理念、架构到实现层面进行深入解读，随着对 Kafka 相关机制的深入了解，这些问题的答案将浮出水面。 须知事项 这篇文档基于 Kafka 最近刚刚发布的 3.2 版本源码为基础进行介绍，主要讨论 Java 和 Scala 语言实现的原版客户端和服务端，其他语言版本的客户端与这篇文档介绍的机制在实现上会有较大出入，需要留意 此外，字节的业务很多使用的都是自研的 BMQ [3]，在客户端协议上是完全兼容的，但是服务端进行了完全的重构，本文介绍的相关服务端机制并不适用 Kafka 整个项目包括 Core、Connect、Streams，只有 Core 这一部分是我们通常说的核心消息引擎组件，另外两个都是基于这个核心实现的上层应用，这篇文章主要介绍的就是 Kafka Core 相关的内容，下面的 「Kafka 的应用架构部分」会对这一点做简要介绍 名词对照 下面的表格给出了 Kafka 中出现的一些高频和重要概念的对照解释 英文名 中文名 解释 备注 KIP Kafka 改进提案 KIP（Kafka Improvement Proposal）是针对 Kafka 的一些重大功能变更的提案，通常包括改进动机、提议的改进内容、接口变更等内容 Partition 分区 一个独立不可再分割的消息队列，分区中会有多个副本保存消息，他们的状态应该是一致的 Kafka 分区副本的同步机制不是纯异步的，有高水位机制去跟踪从副本的同步进度，并且有对应的领导者副本选举机制保证分区整体对外可见的消息都是已提交的 Replica 副本 分区中消息的物理存储单元，通常对应磁盘上的一个日志目录，目录中会对消息文件进一步进行分段保存 Leader Replica 主副本、领导者副本 指一个 Partition 的多个副本中，对外提供读写服务的那个副本 Kafka 集群范围有对等地位的组件是 Controller Consumer 消费者 Kafka 客户端消费侧的一个角色，负责将 Broker 中的消息拉取到客户端本地进行处理，还可以使用 Kafka 提供的消费者组管理机制进行消费进度的跟踪 Consumer Group Leader 消费者组领导者 通常指 Consumer Group 中负责生成分区分配方案的 Consumer 这个概念非常容易和上面的 Leader Replica 混淆 Log start offset 消息起始偏移 Log start offset，Kafka 分区消息可见性的起点 此位置对应一条消息，对外可见可以消费 LSO 上次稳定偏移 Last stable offset，和 Kafka 事务相关的一个偏移 当消费端的参数isolation.level 设置为“read_committed的时候，那么消费者就会忽略事务未提交的消息，既只能消费到LSO(LastStableOffset)的位置 LEO 消息终止偏移 Log end offset，Kafka 分区消息的终点 LEO 是下一条消息将要写入的位置，对外不可见不可供消费 HW 高水位 High water mark，用于控制消息可见性，HW 以下的消息对外可见 HW 的位置可能对应一条消息，但是对外不可见不可以消费，HW 的最大值是 LEO LW 低水位 Low water mark，用于控制消息可见性，LW 及以上的消息对外可见 一般情况下和 Log start offset 可以等价替换，代码里也是这个逻辑 ISR