本文为博主自学笔记整理，内容来源于互联网，如有侵权，请联系删除。
01 | Kafka 介绍
Kafka 是什么？
Apache Kafka 是一款开源的消息引擎系统 Messaging System，就像引擎一样，具备某种能量转换传输的能力。
Kafka 是做什么用的？
根据维基百科的定义，消息引擎系统是一组规范。企业利用这组规范在不同系统之间传递语义准确的消息，实现松耦合的异步式数据传递。
通俗来讲，就是系统 A 发送消息给消息引擎系统，系统 B 从消息引擎系统中读取 A 发送的消息。
如何设计消息的传输格式？
Kafka 使用的是纯二进制的字节序列。消息还是结构化的，只是在使用之前都要将其转换成二进制的字节序列。
怎么把消息传输出去？
常见的有两种方法：
- 点对点模型：系统 A 发送的消息只能被系统 B 接收，其他任何系统都不能读取 A 发送的消息。
- 发布 / 订阅模型：它有一个主题（Topic）的概念，你可以理解成逻辑语义相近的消息容器。发送方称为发布者（Publisher），接收方称为订阅者（Subscriber）。和点对点模型不同的是，这个模型可能存在多个发布者向相同的主题发送消息，而订阅者也可能存在多个，它们都能接收到相同主题的消息。生活中的报纸订阅就是一种典型的发布 / 订阅模型。
为什么不直接发送而要通过消息引擎发送消息？
削峰填谷、解耦、异步。这就是 Kafka 这类消息引擎系统的最大意义所在。
以上游的订单系统为例，Kafka 能够将瞬时增加的订单流量全部以消息形式保存在对应的主题中，既不影响上游服务的 TPS，同时也给下游子服务留出了充足的时间去消费它们。
这就是 Kafka 这类消息引擎系统的最大意义所在。
02 | Kafka 术语
- Record：即消息。Kafka 是消息引擎嘛，这里的消息就是指 Kafka 处理的主要对象。
- Topic：即主题。主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务。
- Broker：Kafka 集群由多个 Broker 组成，Broker 负责接收和处理客户端发送过来的请求，以及对消息进行持久化。
- Replication：即备份机制。把相同的数据拷贝到多台机器上，这些相同的数据称为副本（Replica）;
- Replica：即副本。Kafka 中同一条消息能够被拷贝到多个地方以提供数据冗余，这些地方就是所谓的副本。副本还分为领导者副本和追随者副本，各自有不同的角色划分。副本是在分区层级下的，即每个分区可配置多个副本实现高可用。
- Partition。即分区。分区是指一个有序不变的消息序列，每个主题下可以有多个分区。生产者生产的每条消息只会被发送到一个分区中。
- Offset：即消息位移。表示分区中每条消息的位置信息，是一个单调递增且不变的值。
- Producer：即生产者。向主题发布新消息的应用程序。
- Consumer：即消费者。从主题订阅新消息的应用程序。
- Consumer Offset：即消费者位移。表征消费者消费进度，每个消费者都有自己的消费者位移。
- Consumer Group：即消费者组。多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐。利用 Consumer Group 可以实现点对点模型和发布订阅模型。
- Rebalance：即重平衡。消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。
- Log：即消息日志。Kafka 使用消息日志（Log）来保存数据，一个日志就是磁盘上一个只能追加写（Append-only）消息的物理文件。
- Log Segment：即日志段。Kafka 要定期地删除消息以回收磁盘。怎么删除呢？简单来说就是通过日志段（Log Segment）机制。
Kafka实现高可用的手段
-
Broker：一台Broker挂掉后，其他机器上的Broker也能对外提供服务；
-
Replication：Kafka 定义了两类副本，领导者副本（Leader Replica）和追随者副本（Follower Replica）。前者对外提供服务，这里的对外指的是与客户端程序进行交互；而后者只是被动地追随领导者副本而已，不能与外界进行交互。
生产者总是向领导者副本写消息；而消费者总是从领导者副本读消息。至于追随者副本，它只做一件事：向领导者副本发送请求，请求领导者把最新生产的消息发给它，这样它能保持与领导者的同步。
有了副本机制可以保证数据的持久化或消息不丢失。
-
Rebalance 机制；
Kafka实现伸缩性（Scalability）的手段
倘若领导者副本积累了太多的数据以至于单台 Broker 机器都无法容纳了，此时应该怎么办呢？
Kafka 将数据分割成多份保存在不同的 Broker 上，这种机制就是所谓的分区（Partitioning）。
Kafka实现高吞吐量的手段
- Kafka 使用消息日志（Log）来保存数据，Log 是一个只能追加写（Append-only）消息的物理文件，避免了缓慢的随机 I/O 操作；
- 使用消费者组；（后续内容会解释）
Kafka磁盘回收的过程
在 Kafka 底层，是使用 Log 来保存数据的。一个日志又近一步细分成多个日志段，消息被追加写到当前最新的日志段中，当写满了一个日志段后，Kafka 会自动切分出一个新的日志段，并将老的日志段封存起来。Kafka 在后台还有定时任务会定期地检查老的日志段是否能够被删除，从而实现回收磁盘空间的目的。
分区（Partition）和副本（Replica）的联系
每个分区下可以配置若干个副本，其中只能有 1 个领导者副本和 N-1 个追随者副本。
生产者向分区写入消息，每条消息在分区中的位置信息由一个叫位移（Offset）的数据来表征。分区位移总是从 0 开始，假设一个生产者向一个空分区写入了 10 条消息，那么这 10 条消息的位移依次是 0、1、2、…、9。
到此可以总结 Kafka 的三层消息架构：
- 第一层是主题层，每个主题可以配置 M 个分区，而每个分区又可以配置 N 个副本。
- 第二层是分区层，每个分区的 N 个副本中只能有一个充当领导者角色，对外提供服务；其他 N-1 个副本是追随者副本，只是提供数据冗余之用。
- 第三层是消息层，分区中包含若干条消息，每条消息的位移从 0 开始，依次递增。
总结
上面内容可以用一张图来展示。
03 | Kafka 只是消息引擎系统吗？
Apache Kafka 是消息引擎系统，也是一个分布式流处理平台（Distributed Streaming Platform）。
Kafka 名字的由来
因为 Kafka 系统的写性能很强，所以找了个作家的名字来命名，Jay Kreps（Kafka 作者之一）大学期间上了很多文学课，非常喜欢 Franz Kafka 这个作家。
Kafka 的诞生
Kafka 是 LinkedIn 公司内部孵化的项目。LinkedIn 最开始有强烈的数据强实时处理方面的需求。当时他们碰到的主要问题包括以下两点。
-
数据正确性不足
因为数据的收集主要采用轮询（Polling）的方式，如何确定轮询的间隔时间就变成了一个高度经验化的事情。
-
系统高度定制化
维护成本高。
Kafka 消息引擎系统就是为了解决这些问题，旨在提供三个方面的特性：
- 提供一套 API 实现生产者和消费者；
- 降低网络传输和磁盘存储开销；
- 实现高伸缩性架构。
Kafka 只是消息引擎吗？
Apache Kafka 是消息引擎系统，也是一个分布式流处理平台（Distributed Streaming Platform）。
Kafka 在承接上下游、串联数据流管道方面发挥了重要的作用：所有的数据几乎都要从一个系统流入 Kafka 然后再流向下游的另一个系统中。
这样的使用方式屡见不鲜以至于引发了 Kafka 社区的思考：与其我把数据从一个系统传递到下一个系统中做处理，我为何不自己实现一套流处理框架呢？基于这个考量，Kafka 社区于 0.10.0.0 版本正式推出了流处理组件 Kafka Streams，也正是从这个版本开始，Kafka 正式“变身”为分布式的流处理平台，而不仅仅是消息引擎系统了。
Kafka Streams 流处理平台的优势在哪里？
-
第一点是更容易实现端到端的正确性（Correctness）
Kafka 可以实现端到端的精确一次（Exactly-once）处理语义。
-
第二点是 Kafka 对于流式计算的定位
官网上明确标识 Kafka Streams 是一个用于搭建实时流处理的客户端库而非是一个完整的功能系统。这就是说，你不能期望着 Kafka 提供类似于集群调度、弹性部署等开箱即用的运维特性，你需要自己选择适合的工具或系统来帮助 Kafka 流处理应用实现这些功能。
大型公司的流处理平台一定是大规模部署的，因此具备集群调度功能以及灵活的部署方案是不可或缺的要素。但毕竟这世界上还存在着很多中小企业，它们的流处理数据量并不巨大，逻辑也并不复杂，部署几台或十几台机器足以应付。在这样的需求之下，搭建重量级的完整性平台实在是“杀鸡焉用牛刀”，而这正是 Kafka 流处理组件的用武之地。因此从这个角度来说，未来在流处理框架中，Kafka 应该是有一席之地的。
Kafka 分布式存储
Kafka 作者之一 Jay Kreps 曾经专门写过一篇文章阐述为什么能把Kafka 用作分布式存储。不过目前很少有人这么用。
3219
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
