＜Kafka核心技术与实战＞学习笔记
序言
对于数据密集型应用来说:
- 数据量激增: Kafka 能够有效隔离上下游业务，将上游突增的流量缓存起来，以平滑的方式传导到下游子系统中，避免了流量的不规则冲击
- 数据复杂度增加
- 数据变化速率变快
可以实现:
- 消息引擎应用
- 应用程序集成
- 分布式存储构建
- 流处理应用的开发与部署
消息引擎系统
Apache Kafka 是一款开源的消息引擎系统
Messaging System : 消息传递属性
定义
1.官方版
消息引擎系统是一组规范。企业利用这组规范在不同系统之间传递语义准确的消息，实现松耦合的异步式数据传递
2.民间版
系统 A 发送消息给消息引擎系统，系统 B 从消息引擎系统中读取 A 发送的消息
point:
1.消息引擎传输的对象是消息
2.如何传输消息属于消息引擎设计机制的一部分
消息编码格式
信息表达业务语义而无歧义，同时它还要能最大限度地提供可重用性以及通用性
CSV、XML 亦或是 JSON
Google 的 Protocol Buffer 或 Facebook 的 Thrift
kafka的消息编码格式: 二进制的字节序列
消息还是结构化的，只是在使用之前都要将其转换成二进制的字节序列
传输协议
用什么方法把消息传输出去
1.点对点模型
2.发布 / 订阅模型: 主题（Topic）, 发布者（Publisher）, 订阅者（Subscriber）
可能存在多个发布者向相同的主题发送消息，而订阅者也可能存在多个，它们都能接收到相同主题的消息
Kafka同时支持两种模型
削峰填谷
系统 A 不能直接发送消息给系统 B? 削峰填谷, 缓冲上下游瞬时突发流量，使其更平滑
对于那种发送能力很强的上游系统，如果没有消息引擎的保护，“脆弱”的下游系统可能会直接被压垮导致全链路服务“雪崩”
有效地对抗上游的流量冲击，真正做到将上游的“峰”填满到“谷”中，避免了流量的震荡
发送方和接收方的松耦合，这也在一定程度上简化了应用的开发，减少了系统间不必要的交互
上游的TPS(系统吞吐量)高于下游服务, 压跨下游子系统服务
对上游系统进行限速, 对上游系统而言显然是不合理的
kafka术语
主题（Topic）: 可以为每个业务、每个应用甚至是每类数据都创建专属的主题
生产者（Producer）: 向主题发布消息的客户端应用程序, 生产者程序通常持续不断地向一个或多个主题发送消息
消费者（Consumer）: 订阅这些主题消息的客户端应用程序, 能够同时订阅多个主题的消息
Broker
Kafka 的服务器端由被称为 Broker 的服务进程构成，即一个 Kafka 集群由多个 Broker 组成
Broker 负责接收和处理客户端发送过来的请求，以及对消息进行持久化
高可用1: 虽然多个 Broker 进程能够运行在同一台机器上，但更常见的做法是将不同的 Broker 分散运行在不同的机器上，这样如果集群中某一台机器宕机，即使在它上面运行的所有 Broker 进程都挂掉了，其他机器上的 Broker 也依然能够对外提供服务
副本（Replica）
高可用2: 备份机制. 副本（Replica）, 相同的数据拷贝到多台机器上, 副本的数量可配置
领导者副本（Leader Replica）: 对外提供服务，这里的对外指的是与客户端程序进行交互
追随者副本（Follower Replica）: 被动地追随领导者副本, 不能与外界进行交互
MySQL 的从库是可以处理读操作的，但是在 Kafka 中追随者副本不会对外提供服务
Master-Slave 政治色彩×
Leader-Follower √
副本的工作机制:
领导者副本 :生产者总是向领导者副本写消息；而消费者总是从领导者副本读消息
追随者副本: 向领导者副本发送请求，请求领导者把最新生产的消息发给它，这样它能保持与领导者的同步
分区（Partitioning）机制
伸缩性(Scalability)问题
如果领导者副本积累了太多的数据以至于单台 Broker 机器都无法容纳了
把数据分割成多份保存在不同的 Broker 上 – > 分区机制
MongoDB 和 Elasticsearch 中的 Sharding、HBase 中的 Region
kafka的分区机制
将每个主题划分成多个分区（Partition），每个分区是一组有序的消息日志
生产者生产的每条消息只会被发送到一个分区中，也就是说如果向一个双分区的主题发送一条消息，这条消息要么在分区 0 中，要么在分区 1 中
Kafka 的分区编号是从 0 开始的，如果 Topic 有 100 个分区，那么它们的分区号就是从 0 到 99
分区+副本
每个分区下可以配置若干个副本，其中只能有 1 个领导者副本和 N-1 个追随者副本
生产者向分区写入消息，每条消息在分区中的位置信息由一个叫位移（Offset）的数据来表征
分区位移总是从 0 开始，假设一个生产者向一个空分区写入了 10 条消息，那么这 10 条消息的位移依次是 0、1、2、…、9
Kafka 的三层消息架构
- 主题层，每个主题可以配置 M 个分区，而每个分区又可以配置 N 个副本
- 分区层，每个分区的 N 个副本中只能有一个充当领导者角色，对外提供服务；其他 N-1 个副本是追随者副本，只是提供数据冗余之用。
- 消息层，分区中包含若干条消息，每条消息的位移从 0 开始，依次递增
客户端程序只能与分区的领导者副本进行交互
Kafka Broker 持久化数据
Kafka 使用消息日志（Log）来保存数据，一个日志就是磁盘上一个只能追加写（Append-only）消息的物理文件
因为只能追加写入，故避免了缓慢的随机 I/O 操作，改为性能较好的顺序 I/O 写操作，这也是实现 Kafka 高吞吐量特性的一个重要手段
不过如果不停地向一个日志写入消息，最终也会耗尽所有的磁盘空间，因此 Kafka 必然要定期地删除消息以回收磁盘
通过日志段（Log Segment）机制
在 Kafka 底层，一个日志又进一步细分成多个日志段，消息被追加写到当前最新的日志段中，当写满了一个日志段后，Kafka 会自动切分出一个新的日志段，并将老的日志段封存起来
Kafka 在后台还有定时任务会定期地检查老的日志段是否能够被删除，从而实现回收磁盘空间的目的
消费者组（Consumer Group）
多个消费者实例共同组成一个组来消费一组主题
这组主题中的每个分区都只会被组内的一个消费者实例消费，其他消费者实例不能消费它
kafka引入消费者组的目的:提升消费者端的吞吐量
多个消费者实例同时消费，加速整个消费端的吞吐量（TPS）
消费者实例可以是运行消费者应用的进程，也可以是一个线程，它们都称为一个消费者实例（Consumer Instance）
重平衡
消费者组里面的所有消费者实例不仅“瓜分”订阅主题的数据，而且它们还能彼此协助
假设组内某个实例挂掉了，Kafka 能够自动检测到，然后把这个 Failed 实例之前负责的分区转移给其他活着的消费者
每个消费者在消费消息的过程中必然需要有个字段记录它当前消费到了分区的哪个位置上，这个字段就是消费者位移（Consumer Offset）
分区位移 vs 消费者位移
分区位移: 表征的是分区内的消息位置，它是不变的，即一旦消息被成功写入到一个分区上，它的位移值就是固定的
消费者位移: 它可能是随时变化的，是消费者消费进度的指示器. 每个消费者有着自己的消费者位移
总结
- 消息：Record。Kafka 是消息引擎, 消息就是指 Kafka 处理的主要对象
- 主题：Topic。主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务
- 分区：Partition。一个有序不变的消息序列。每个主题下可以有多个分区
- 消息位移：Offset。表示分区中每条消息的位置信息，是一个单调递增且不变的值
- 副本：Replica。Kafka 中同一条消息能够被拷贝到多个地方以提供数据冗余，这些地方就是所谓的副本。副本还分为领导者副本和追随者副本，各自有不同的角色划分。副本是在分区层级下的，即
每个分区可配置多个副本实现高可用 - 生产者：Producer。向主题发布新消息的应用程序
- 消费者：Consumer。从主题订阅新消息的应用程序
- 消费者位移：Consumer Offset。表征消费者消费进度，每个消费者都有自己的消费者位移
- 消费者组：Consumer Group。多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐
- 重平衡：Rebalance。消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。
Rebalance 是 Kafka 消费者端实现高可用的重要手段
思考: 为什么 Kafka 不像 MySQL 那样允许追随者副本对外提供读服务？
不从follower读几个原因：
1，kafka的分区已经让读是从多个broker读从而负载均衡，不是MySQL的主从，压力都在主上；
2，kafka保存的数据和数据库的性质有实质的区别就是数据具有消费的概念，是流数据，kafka是消息队列，所以消费需要位移，而数据库是实体数据不存在这个概念，如果从kafka的follower读，消费端offset控制更复杂；
3，生产者来说，kafka可以通过配置来控制是否等待follower对消息确认的，如果从上面读，也需要所有的follower都确认了才可以回复生产者，造成性能下降，如果follower出问题了也不好处理
Apache Kafka 是消息引擎系统，也是一个分布式流处理平台
LinkedIn公司问题:
- 数据正确性不足。因为数据的收集主要采用
轮询（Polling）的方式，如何确定轮询的间隔时间就变成了一个高度经验化的事情。虽然可以采用一些类似于启发式算法（Heuristic）来帮助评估间隔时间值，但一旦指定不当，必然会造成较大的数据偏差 - 系统高度定制化，维护成本高。各个业务子系统都需要对接数据收集模块，引入了大量的定制开销和人工成本
kafka定位
一个分布式、分区化且带备份功能的提交日志（Commit Log）服务
kafka设计旨在提供特性
- 提供一套 API 实现生产者和消费者；降低网络传输和磁盘存储开销；实现高伸缩性架构
- 降低网络传输和磁盘存储开销
- 实现高伸缩性架构
流处理
- 开源之后的 Kafka 被越来越多的公司应用到它们企业内部的数据管道中，特别是在大数据工程领域，Kafka 在承接上下游、串联数据流管道方面发挥了重要的作用：所有的数据几乎都要从一个系统流入 Kafka 然后再流向下游的另一个系统中
- 这样的使用方式屡见不鲜以至于引发了 Kafka 社区的思考：与其把数据从一个系统传递到下一个系统中做处理，为何不自己实现一套
流处理框架呢？基于这个考量，Kafka 社区于 0.10.0.0 版本正式推出了流处理组件 Kafka Streams，也正是从这个版本开始，Kafka 正式“变身”为分布式的流处理平台，而不仅仅是消息引擎系统了。 - 今天 Apache Kafka 是和 Apache Storm、Apache Spark 和 Apache Flink 同等级的实时流处理平台
作为流处理平台，Kafka 与其他主流大数据流式计算框架相比的优势
-
更容易实现端到端的正确性（Correctness）
Google 大神 Tyler 曾经说过，流处理要最终替代它的“兄弟”批处理需要具备两点核心优势：要实现正确性和提供能够推导时间的工具。实现正确性是流处理能够匹敌批处理的基石。
正确性一直是批处理的强项，而实现正确性的基石则是要求框架能提供精确一次处理语义，即处理一条消息有且只有一次机会能够影响系统状态。
目前主流的大数据流处理框架都宣称实现了精确一次处理语义，但这是有限定条件的，即它们只能实现框架内的精确一次处理语义，无法实现端到端的。
因为当这些框架与外部消息引擎系统结合使用时，它们无法影响到外部系统的处理语义，所以如果搭建了一套环境使得 Spark 或 Flink 从 Kafka 读取消息之后进行有状态的数据计算，最后再写回 Kafka，那么只能保证在 Spark 或 Flink 内部，这条消息对于状态的影响只有一次。
但是计算结果有可能多次写入到 Kafka，因为它们不能控制 Kafka 的语义处理。相反地，Kafka 则不是这样，因为所有的数据流转和计算都在 Kafka 内部完成，故 Kafka 可以实现端到端的精确一次处理语义 -
对于流式计算的定位。官网上明确标识 Kafka Streams 是一个用于搭建实时流处理的客户端库而非是一个完整的功能系统。这就是说，不能期望着 Kafka 提供类似于
集群调度、弹性部署等开箱即用的运维特性，需要自己选择适合的工具或系统来帮助 Kafka 流处理应用实现这些功能。
这怎么算是优点呢？坦率来说，这的确是一个“双刃剑”的设计，也是 Kafka 社区“剑走偏锋”不正面 PK 其他流计算框架的特意考量。
大型公司的流处理平台一定是大规模部署的，因此具备集群调度功能以及灵活的部署方案是不可或缺的要素。但毕竟这世界上还存在着很多中小企业，它们的流处理数据量并不巨大，逻辑也并不复杂，部署几台或十几台机器足以应付。
在这样的需求之下，搭建重量级的完整性平台实在是“杀鸡焉用牛刀”，而这正是 Kafka 流处理组件的用武之地。因此从这个角度来说，未来在流处理框架中，Kafka 应该是有一席之地的
kafka其他用途
总结
Apache Kafka 从一个优秀的消息引擎系统起家，逐渐演变成现在分布式的流处理平台
不同版本的kafka
-
Apache Kafka，也称社区版
Kafka。优势在于迭代速度快，社区响应度高，使用它可以有更高的把控度；缺陷在于仅提供基础核心组件，缺失一些高级的特性。 -
Confluent Kafka，Confluent 公司提供的 Kafka。优势在于集成了很多高级特性且由 Kafka 原班人马打造，质量上有保证；缺陷在于相关文档资料不全，普及率较低，没有太多可供参考的范例。
-
CDH/HDP Kafka，大数据云公司提供的 Kafka，内嵌 Apache Kafka。优势在于操作简单，节省运维成本；缺陷在于把控度低，演进速度较慢。
Kafka版本
- 前面的版本号是编译 Kafka 源代码的
Scala 编译器版本
Kafka 服务器端的代码完全由 Scala 语言编写，Scala 同时支持面向对象编程和函数式编程，用 Scala 写成的源代码编译之后也是普通的“.class”文件，因此可以说 Scala 是 JVM 系的语言，它的很多设计思想都是为人称道的 - 对于 kafka-2.11-2.1.1 的提法，真正的 Kafka 版本号实际上是 2.1.1
- 前面的 2 表示大版本号，即 Major Version；中间的 1 表示小版本号或次版本号，即 Minor Version；最后的 1 表示修订版本号，也就是 Patch 号
- Kafka 社区在发布 1.0.0 版本后特意写过一篇文章，宣布 Kafka 版本命名规则正式从 4 位演进到 3 位，比如 0.11.0.0 版本就是 4 位版本号
扫一扫
886
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
