Kafka(Go)教程(三)---Kafka 相关概念介绍

本文为 Kafka 入门教程,主要包括相关概念介绍如： 消息引擎、 Kafka 相关术语、角色定位及其版本选择等等。

1. 消息引擎

Kafka 系列相关代码见 Github

Kafka 是什么呢？

用一句话概括一下：Apache Kafka 是一款开源的消息引擎系统。

消息引擎系统 这个词可能比较陌生，国内一般用得多的是消息队列或者消息中间件。不过相比之下 消息引擎系统 这个称谓可能更合适。

• 消息队列给出了一个很不明确的暗示，仿佛 Kafka 是利用队列的方式构建的；
• 而消息中间件的提法有过度夸张“中间件”之嫌，让人搞不清楚这个中间件到底是做什么的。
• 消息引擎系统则更能提现出消息传递属性，就像引擎一样，具备某种能量转换传输的能力。

像 Kafka 这一类的系统国外有专属的名字叫 Messaging System，国内很多文献将其简单翻译成消息系统。

目前国内在翻译国外专有技术词汇方面做得确实够标准化，比如 Raft 算法和 Paxos 算法都属于 Consensus Algorithm 一族。但是国内一般称为 一致性算法，实际上 共识算法 比较准确。国外的 Consistency 被称为一致性、Consensus 也唤作一致性，甚至是 Coherence 都翻译成一致性。

消息系统有什么作用？脑子里想到的第一个词肯定是削峰填谷。

所谓的“削峰填谷”就是指缓冲上下游瞬时突发流量，使其更平滑。

比如下游系统处理能力为 10，上游压力则是在0~20动态变化的。假设第一秒上游压力为 20，第二秒为 0 ,如果没有消息系统直接把 20 的压力给到下游，由于处理不过来，有 10 的请求肯定会超时，然后第二秒没有压力下游也只能闲着。有消息系统后，直接将上游压力写入 消息系统，下游从消息系统中取出消息来处理，这样第一秒处理 10个，第二秒再处理 10 个，一直处于忙碌状态也不会出现超时的问题。

一个形象的比喻就是：

• 用消息系统之前就是抱着水管喝水，水管出水量不会因为你喝不过来就变小；
• 用消息系统之后就是拿瓶子喝水，每次倒多少水可以由自己控制。

2. Kafka 相关术语

Kafka 里的一些术语是其他 MQ 没有的，这里先提一下，后面遇到时能大致有个印象就行。

• 消息：Record。Kafka 是消息引擎嘛，这里的消息就是指 Kafka 处理的主要对象。

• 主题：Topic。主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务。

• 分区：Partition。一个有序不变的消息序列。每个主题下可以有多个分区。

• 消息位移：Offset。表示分区中每条消息的位置信息，是一个单调递增且不变的值。

• 副本：Replica。Kafka 中同一条消息能够被拷贝到多个地方以提供数据冗余，这些地方就是所谓的副本。副本还分为领导者副本和追随者副本，各自有不同的角色划分。副本是在分区层级下的，即每个分区可配置多个副本实现高可用。

• 生产者：Producer。向主题发布新消息的应用程序。

• 消费者：Consumer。从主题订阅新消息的应用程序。

• 消费者位移：Consumer Offset。表征消费者消费进度，每个消费者都有自己的消费者位移。

• 消费者组：Consumer Group。多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐。

• 重平衡：Rebalance。消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。

3. Kafka 角色定位

Kafka 在设计之初就旨在提供三个方面的特性：

• 提供一套 API 实现生产者和消费者；
• 降低网络传输和磁盘存储开销；
• 实现高伸缩性架构。

Apache Kafka 真的只是消息引擎吗？

目前 Kafka 官方文档写的是 Apache Kafka is an event streaming platform。即 Apache Kafka 不仅是消息引擎系统，还是一个流处理平台（Streaming Platform）。

Apache Kafka 从一个优秀的消息引擎系统起家，逐渐演变成现在分布式的流处理平台。

Kafka 社区于 0.10.0.0 版本正式推出了流处理组件 Kafka Streams，也正是从这个版本开始，Kafka 正式“变身”为分布式的流处理平台，而不仅仅是消息引擎系统了。

作为流处理平台，Kafka 与其他主流大数据流式计算框架相比，优势在哪里呢？

大概是 Kafka 自己对于流式计算的定位。官网上明确标识 Kafka Streams 是一个用于搭建实时流处理的客户端库而非是一个完整的功能系统。

对于中小企业来说，它们的流处理数据量并不巨大，逻辑也并不复杂，搭建重量级的完整性平台实在是“杀鸡焉用牛刀”，而这正是 Kafka 流处理组件的用武之地。

4. Kafka 类型选择

目前 有 3 种 Kafka 可供选择：

Apache Kafka 一般日常提到的 Kafka 都指的是 Apache Kafka，这是最“正宗”的 Kafka，也称为 社区版 Kafka。

Confluent Kafka，Confluent 公司是 Kafka 的 3 个创始人 Jay Kreps、Naha Narkhede 和饶军离开 LinkedIn 创办的，它主要从事商业化 Kafka 工具开发，并在此基础上发布了 Confluent Kafka。Confluent Kafka 提供了一些 Apache Kafka 没有的高级特性，比如跨数据中心备份、Schema 注册中心以及集群监控工具等。

Cloudera/Hortonworks Kafka：Cloudera 提供的 CDH 和 Hortonworks 提供的 HDP 是非常著名的大数据平台，里面集成了目前主流的大数据框架，当然也包括 Apache Kafka，因此我把这两款产品中的 Kafka 称为 CDH Kafka 和 HDP Kafka。

特点比较

Apache Kafka 它现在依然是开发人数最多、版本迭代速度最快的 Kafka，且社区比较活跃，对开发者友好。劣势在于它仅仅提供最最基础的组件，没有提供任何监控框架或工具。

如果你仅仅需要一个消息引擎系统亦或是简单的流处理应用场景，同时需要对系统有较大把控度，那么我推荐你使用 Apache Kafka。

Confluent Kafka 目前分为免费版和企业版两种。前者和 Apache Kafka 非常相像，除了常规的组件之外，免费版还包含 Schema 注册中心和 REST proxy 两大功能。后者用开放 HTTP 接口的方式允许你通过网络访问 Kafka 的各种功能，这两个都是 Apache Kafka 所没有的。

如果你需要用到 Kafka 的一些高级特性，那么推荐你使用 Confluent Kafka。

CDH/HDP Kafka，这些大数据平台天然集成了 Apache Kafka，通过便捷化的界面操作将 Kafka 的安装、运维、管理、监控全部统一在控制台中。使用起来非常方便，不过这样做的结果是直接降低了你对 Kafka 集群的掌控程度。

5. Kafka 演进历史

目前 Kafka 已经迭代到了 2.8.0 版本。再下载 Kafka 时会发现 Kafka 的版本号大概是这样的:

• Scala 2.12 - kafka_2.12-2.8.0.gz
• Scala 2.13 - kafka_2.13-2.8.0.gz

前面的版本号是编译 Kafka 源代码的 Scala 编译器版本,如 2.12 或者 2.13。

Kafka 服务器端的代码完全由 Scala 语言编写

后面 2.8.0 才是 Kafka 的版本号。由 3 个部分构成，即“大版本号 - 小版本号 - Patch 号“。

版本演进历史

最后还有个建议，不论你用的是哪个版本，都请尽量保持服务器端版本和客户端版本一致，否则你将损失很多 Kafka 为你提供的性能优化收益。

还有就是在生产环境不要贸然升级到最新版本，新版本多多少少都存在一些小问题，至少要在测试环境确认没问题后再升级。

Kafka 系列相关代码见 Github

6. 参考

https://kafka.apache.org/documentation

《Kafka 核心技术与实战》