Kafka简介

Kafka 是什么
1、Kafka 概述
在流式计算中，Kafka 一般用来缓存数据，Storm 通过消费 Kafka 的数据进行计算。
经典架构：Flume + Kafka + Storm/SparkStreaming + Redis
Apache Kafka 最初是是由 LinkedIn 开发的一个基于发布订阅的分布式的消息系统，由
Scala/Java 编写，并于 2011 年初开源。2012 年 10 月从 Apache Incubator 毕业，现在是 Apache
软件基金会负责维护的一个顶级开源消息系统项目。该项目的目标是为处理实时数据提供一
个统一、高通量、低等待的平台。它以可水平扩展和高吞吐率而被广泛使用。目前越来越多
的开源分布式处理系统如 Cloudera、Apache Storm、Spark 都支持与 Kafka 集成。
Kafka 是一个分布式消息队列：具有生产者、消费者的功能。它提供了类似于 JMS 的特性，
但是在设计实现上完全不同，此外它并不是 JMS 规范的实现。
Kafka 对消息保存时根据 Topic 进行归类，发送消息者称为 Producer，消息接受者称为
Consumer，此外 Kafka 集群有多个 Kafka 实例组成，每个实例(server)成为 broker。
无论是Kafka集群，还是Producer和Consumer都依赖于ZooKeeper集群保存一些meta信息，
来保证系统可用性
Kafka 官网：http://kafka.apache.org/

2、Kafka 特性
高吞吐量、低延迟：kafka 每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个 topic
可以分多个 partition，consumer group 对 partition 进行消费操作
可扩展性：kafka 集群支持热扩展
持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
容错性：允许集群中节点失败（若副本数量为 n，则允许 n-1 个节点失败）
高并发：支持数千个客户端同时读写

Kafka 的应用场景
1、第一个：消息系统
Kafka 很好地替代了传统的 message broker（消息代理）。Message Brokers 可用于各种场合（如
将数据生成器与数据处理解耦，缓冲未处理的消息等）。与大多数消息系统相比，Kafka 拥有
更好的吞吐量、内置分区、具有复制和容错的功能，这使它成为一个非常理想的大型消息处
理应用。根据我们的经验，通常消息传递使用较低的吞吐量，但可能要求较低的端到端延迟，
Kafka 提供强大的持久性来满足这一要求。在这方面，Kafka 可以与传统的消息传递系统
（ActiveMQ 和 RabbitMQ）相媲美。
2、第二个：跟踪网站活动
Kafka 的初始用例是将用户活动跟踪管道重建为一组实时发布-订阅源。这意味着网站活动
（浏览网页、搜索或其他的用户操作）将被发布到中心 topic，其中每个活动类型有一个 topic。
这些订阅源提供一系列用例，包括实时处理、实时监视、对加载到 Hadoop 或离线数据仓库
系统的数据进行离线处理和报告等。每个用户浏览网页时都生成了许多活动信息，因此活动
跟踪的数据量通常非常大
3、第三个：运营指标
Kafka 也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集
中反馈，比如报警和报告。
4、第四个：日志聚合
许多人使用 Kafka 来替代日志聚合解决方案。日志聚合系统通常从服务器收集物理日志文件，
并将其置于一个中心系统（可能是文件服务器或 HDFS）进行处理。Kafka 从这些日志文件中
提取信息，并将其抽象为一个更加清晰的消息流。这样可以实现更低的延迟处理且易于支持
多个数据源及分布式数据的消耗。与 Scribe 或 Flume 等以日志为中心的系统相比，Kafka 具
备同样出色的性能、更强的耐用性（因为复制功能）和更低的端到端延迟。
5、第五个：流处理
许多 Kafka 用户通过管道来处理数据，有多个阶段：从 Kafka topic 中消费原始输入数据，然
后聚合，修饰或通过其他方式转化为新的 topic，以供进一步消费或处理。 例如，一个推荐
新闻文章的处理管道可以从 RSS 订阅源抓取文章内容并将其发布到“文章”topic; 然后对这
个内容进行标准化或者重复的内容，并将处理完的文章内容发布到新的 topic; 最终它会尝试
将这些内容推荐给用户。这种处理管道基于各个 topic 创建实时数据流图。从 0.10.0.0 开始，
在 Apache Kafka 中，Kafka Streams 可以用来执行上述的数据处理，它是一个轻量但功能强大
的流处理库。除 Kafka Streams 外，可供替代的开源流处理工具还包括 Apache Storm 和 Apache
Samza。
6、第六个：采集日志
Event Sourcing 是一种应用程序设计风格，按时间来记录状态的更改。Kafka 可以存储非常多
的日志数据，为基于 Event Sourcing 的应用程序提供强有力的支持。
7、第七个：提交日志
Kafka 可以从外部为分布式系统提供日志提交功能。日志有助于记录节点和行为间的数据，
采用重新同步机制可以从失败节点恢复数据。Kafka 的日志压缩功能支持这一用法。这一点
与 Apache BookKeeper 项目类似。

Kafka 核心组件
1、Kafka 核心组件概述
Kafka 是 LinkedIn 用于日志处理的分布式消息队列，同时支持离线和在线日志处理。
Kafka 对消息保存时根据 Topic 进行归类：
发送消息者就是 Producer，消息的发布描述为 Producer
消息接受者就是 Consumer，消息的订阅描述为 Consumer
每个 Kafka 实例称为 Broker，将中间的存储阵列称作 Broker(代理)

然后三者都通过 Zookeeper 进行协调。
Kafka 的大致工作模式：
1、启动 ZooKeeper 的 server
2、启动 Kafka 的 server
3、Producer 生产数据，然后通过 ZooKeeper 找到 Broker，再将数据 push 到 Broker 保存
4、Consumer 通过 ZooKeeper 找到 Broker，然后再主动 pull 数据

Kafka 的核心概念详解
Producer : 生产 message 发送到 topic
Consumer : 订阅 topic 消费 message，consumer 作为一个线程来消费
Consumer Group：一个 Consumer Group 包含多个 consumer，这个是预先在配置文件中配置
好的
Broker：Kafka 节点，一个 Kafka 节点就是一个 broker，多个 broker 可以组成一个 Kafka 集群。
Topic：一类消息，消息存放的目录即主题，例如 page view 日志、click 日志等都可以以 topic
的形式存在，Kafka 集群能够同时负责多个 topic 的分发。
Partition：topic 物理上的分组，一个 topic 可以分为多个 partition，每个 partition 是一个有
序的队列
Segment：partition 物理上由多个 segment 组成，每个 Segment 存着 message 信息
1、生产者：Producer
学习 Kafka 一定要理解好 Topic，每个 Topic 被分成多个 partition(区)。每条消息在 partition
中的位置称为 offset(偏移量)，类型为 long 型数字。消息即使被消费了，也不会被立即删除，
而是根据 broker 里的设置，保存一定时间后再清除，比如 log 文件设置存储两天，则两天后，
不管消息是否被消费，都清除。

2、Kafka 集群的存储代理：Broker
Broker 也即中间的存储队列的节点实例。我们将消息的发布者（Publisher）暂时称作
Producer，将消息的订阅者（Subscriber）表述为 Consumer，将中间的存储阵列称作 Broker(代
理)

3、消费者组：Consumer Group
一个Consumer Group包含多个consumer，这个是预先在配置文件中配置好的。各个consumer
（consumer 线程）可以组成一个组（Consumer Group），partition 中的每个 message 只能被
组（Consumer group）中的一个 consumer（consumer 线程或者一个消费者程序）消费，如
果一个 message 可以被多个 consumer（consumer 线程）消费的话，那么这些 consumer 必
须在不同的组。Kafka不支持一个partition中的message由两个或两个以上的consumer thread
来处理，即便是来自不同的 consumer group 的也不行。它不能像 AMQ 那样可以多个 BET 作
为 consumer 去处理 message，这是因为多个 BET 去消费一个 Queue 中的数据的时候，由于
要保证不能多个线程拿同一条 message，所以就需要行级别悲观锁（for update），这就导致
了 consume 的性能下降，吞吐量不够。而 kafka 为了保证吞吐量，只允许一个 consumer 线
程去访问一个 partition。如果觉得效率不高的时候，可以加 partition 的数量来横向扩展，那
么再加新的 consumer thread 去消费。这样没有锁竞争，充分发挥了横向的扩展性，吞吐量
极高。这也就形成了分布式消费的概念。当启动一个 consumer group 去消费一个 topic 的时
候，无论 topic 里面有多个少个 partition，无论我们 consumer group 里面配置了多少个
consumer thread，这个 consumer group 下面的所有 consumer thread 一定会消费全部的
partition；即便这个 consumer group 下只有一个 consumer thread，那么这个 consumer thread
也会去消费所有的 partition。因此，最优的设计就是，consumer group 下的 consumer thread
的数量等于 partition 数量，这样效率是最高的。
![在
Consumer Rebalance 的触发条件：
（1）Consumer 增加或删除会触发 Consumer Group 的 Rebalance
（2）Broker 的增加或者减少都会触发 Consumer Rebalance

如何实现单播？如何实现广播
如果需要实现广播，只要每个 consumer 有一个独立的 CG 就可以了。要实现单播只要所有
的 consumer 在同一个 CG

4、消费者：Consumer
每个 Consumer 属于一个 Consumer Group
在 kafka 中：
1、 一个 Partition 的消息只会被 group 中的一个 Consumer 消费
2、 可以认为一个 group 就是一个“订阅者”
3、 一个 Topic 中的每个 Partition 只会被一个“订阅者”中的一个 Consumer 消费
消费者使用一个消费组名称来进行标识，发布到 topic 中的每条记录被分配给订阅消费组中
的一个消费者实例。消费者实例可以分布在多个进程中或者多个机器上。
如果所有的消费者实例在同一消费组中，消息记录会负载平衡到每一个消费者实例。
如果所有的消费者实例在不同的消费组中，每条消息记录会广播到所有的消费者进程。

如图，这个 Kafka 集群有两台 server 的，四个分区(p0-p3)和两个消费者组。
消费组 A 有两个消费者，消费组 B 有四个消费者。
通常情况下，每个 topic 都会有一些消费组，一个消费组对应一个"逻辑订阅者"。一个消费
组由许多消费者实例组成，便于扩展和容错。这就是发布和订阅的概念，只不过订阅者是一
组消费者而不是单个的进程。
在 Kafka 中实现消费的方式是将日志中的分区划分到每一个消费者实例上，以便在任何时间，
每个实例都是分区唯一的消费者。维护消费组中的消费关系由 Kafka 协议动态处理。如果新
的实例加入组，他们将从组中其他成员处接管一些 Partition 分区；如果一个实例消失，拥
有的分区将被分发到剩余的实例。
Kafka 只保证分区内的记录是有序的，而不保证主题中不同分区的顺序。每个 partition 分
区按照 key 值排序足以满足大多数应用程序的需求。但如果你需要总记录在所有记录的上
面，可使用仅有一个分区的主题来实现，这意味着每个消费者组只有一个消费者进程。