1. Kafka 简介
Kafka是一种分布式的，基于发布/订阅的消息系统，起源于 LinkedIn，用作 LinkedIn 的活动流和运营数据处理管道的基础。它有以下一些性能特性：
- 能够以 O(1) 的时间复杂度提供消息持久化能力，即使对 TB 级以上的数据也能保证常熟时间复杂度的访问性能；
- 高吞吐量，即使在非常廉价的商用机器上也能做到单机支持每秒 100k 条以上消息的传输；
- 支持 kafka Server 间的消息分区及分布式消费，同时能保证每个 partition 内的消息顺序传输；
- 支持离线数据处理和实时数据处理；
- Scale out ： 支持在线水平扩展；
2. Kafka 的应用场景
- 消息队列
kafka 可以用作消息中间件来代替传统的消息系统。Kafka能提供较高的吞吐量，较低的端到端延迟，多副本，容错功能以及强大的持久性保证。
- 日志聚合
日志搜集通常从服务器收集物理日志文件，并将它们集中放置（可能是文件服务器或HDFS）以便后续处理。kafka抽象出文件的细节，并将日志或事件数据作为消息流清晰地抽象出来。这可以为更低处理延迟提供支持，多数据源和分布式数据消费更容易支持。与以日志为中心的系统（如Scribe或Flume）相比，Kafka性能同样出色，由于副本机制确保了更强的耐用性保，并且端到端延迟更低。
- 监控测量
kafka经常用于运行监控数据。这涉及汇总分布式应用程序的统计数据，以产生操作运营数据的汇总数据。
- 网站行为跟踪
Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到Hadoop、数据仓库中做离线分析和挖掘
- 流处理
spark streaming和storm。保存收集流数据，以提供之后对接的Storm或其他流式计算框架进行处理。很多用户会将那些从原始 topic 来的数据进行阶段性处理，汇总，扩充或者以其他的方式转换到新的 topic 下再继续后面的处理。例如一个文章推荐的处理流程，可能是先从RSS数据源中抓取文章的内容，然后将其丢入一个叫做“文章”的topic中；后续操作可能是需要对这个内容进行清理，比如回复正常数据或者删除重复数据，最后再将内容匹配的结果返还给用户。这就在一个独立的topic之外，产生了一系列的实时数据处理的流程。Strom和Samza是非常著名的实现这种类型数据转换的框架。
- 事件源
事件源是一种应用程序设计的方式，该方式的状态转移被记录为按时间顺序排序的记录序列。Kafka可以存储大量的日志数据，这使得它成为一个对这种方式的应用来说绝佳的后台。比如动态汇总（News feed）。
- 提交日志
Kafka可以为一种外部的持久性日志的分布式系统提供服务。这种日志可以在节点间备份数据，并为故障节点数据回复提供一种重新同步的机制。具体来讲，我们可以将数据库的更新发布到 Kafka 上，应用程序通过监控事件流来接收数据库的实时更新。这种变更日志也可以用于把数据库的更新复制到远程系统上，或者合并多个应用程序的更新到一个单独的数据库视图上。数据持久化为变更日志提供了缓冲区，如果消费者应用程序发生故障，可以通过重放这些日志来恢复系统状态。
3. Kafka 的结构与基本概念
3.1 Kafka 的拓扑结构
如下图所示，为一个典型的kafka集群
一个kafka集群包含以下几个部分：
- 若干生产者 Producer
- 若干用来存放消息的kafka服务器 Broker
- 若干消费者群组 Consumer Group，Consumer Group中由一个或多个 Consumer 组成
- 管理集群配置的 zookeeper
整个kafka集群工作模式为：Producer 使用 push 模式将消息发布到 broker，comsumer 使用 pull 模式从 broker 订阅并消费消息，整个集群基于 zookeeper 来进行集群管理，负载均衡等。这里面涉及到这样一些术语：
- Broker
kafka 集群包含一个或多个服务器，每个独立的 kafka 服务器被称为 broker。对于生产者，broker 接收来自生产者的消息，为消息设置 offset，并提交消息到磁盘保存。对于消费者，broker 为消费者读取分区的请求作出响应，返回分区上的消息。
- Producer
负责发布消息到 broker 上的对象。
- Comsumer
消息消费者，从 broker 上订阅消息并处理这些消息 。
- Comsumer Group
若干 Comsumer 组成的一个消费者集合，与传统的发布-订阅消息系统不同，kafka 是将消息广播到各个 Comsumer Group 上，而不是单个的 Comsumer 上。
- Topic
kafka 为消息做的逻辑归类，一个消息类别就是一个 topic。可以认为 topic 是一个逻辑上 queue，每条消息都必须制定它的 topic，生产者与消费者也要通过 topic name 来 push 或者 pull 消息。
- Partition
topic 是一个逻辑上的抽象概念，它具体是由 partition 作物理呈现。一个 topic 被分成多个 partition 存放在不同的服务器上，一个 partition 在服务器上对应的是一个具体的文件目录，目录下存放的是消息文件和索引文件。
- Segment
kafka 还将 partition 进一步分割成多个段（segment），一个段对应一个服务器上的log文件。这样分割好处之一就是在清理过期的消息时，可以对整个段的文件作删除操作，从而避免对文件的随机写操作，提高吞吐量。
3.2 Topic、Partition、Segment 的关系
Kafka 中的消息是以 topic 来进行分类的，一个 topic 又被分成多个 partition，而 partition 还可以被进一步细分为若干个 segment。那么这三者具体的呈现是什么呢？下面是这三者之间的一个示意图：
- Topic
Topic是一个消息投递目标的名称，它是一个逻辑上的概念。生产者通过 topic 向 broker 发送消息，消费者通过订阅相应的 topic， 读取特定一类的消息。
- Partition
Partition 是 topic 的物理层面上的具体分组，每个 partition 为一个目录，其命名规范为 topicName + 有序序号，序号从 0 开始。每个 partition 都是一个顺序的、不可变的消息队列，每发布到该 partition 一条消息就追加到其 log 文件的尾部。并且，partition 中的每条消息都被分了一个序列号，这个序列号称之为偏移量（offset）。offset 是一个 long 型的数字，它唯一标记一条消息。消费者通过控制 offset 来定位读取 partition 中所要消息。
Kafka 将 topic 拆分成多个 partition 主要有两个目的：
- 支持水平扩展，可以将不同的 partition 放在不同的服务器上，这样的话，消息文件的体积将不再受限于单个服务器的磁盘容量，一个topic可以处理任意数量的数据。
- partition 可以作为并行单元，使得消息可以被多个 comsumer 并行处理（只要将comsumer分布于不同的 group），可以系统效率。
- Segment
Segment 是对 partition 的进一步细分，它物理上对应到 partition 目录下的具体 log 文件，以 19 位数字命名规则为：第一个 segment 命名为全0，后续的 segment 文件名为最后一条消息的 offset 值（位数不足左补0）。每个 segment 文件最大存储量是固定的，可以在配置文件中进行配置。当一个 segment 文件超出设定最大存储量时，就会创建下一个 segment 文件来存放下一条消息。每个 segment 由两部分组成： 消息数据文件(.log) 和 索引(.index) 。将 partition 分割成多个 segment 文件可以很方便的清理过期的消息（直接删除过期的segment文件，而不用再去随机写磁盘上的log文件）。
3.3 Comsumer 与 Comsumer Group
传统的消息有两种模式：队列和发布订阅。
- 队列模式：消费者池从服务器读取消息（每个消息只被其中一个读取）。
- 发布-订阅模式：消息广播给所有的消费者。
这两种模式都有优缺点，队列的优点是允许多个消费者瓜分处理数据，这样可以扩展处理。但是，队列不像多个订阅者，一旦消息者进程读取后故障了，那么消息就丢了。而发布和订阅允许你广播数据到多个消费者，由于每个订阅者都订阅了消息，所以没办法缩放处理。
kafka 将这两者做了结合与抽象，提出了消费者组（Comsumer Group）的概念。每个 comsumer 都有一个自己的消费者组名标识，因此多个相同标识的 comsumer 就组成了一个 comsumer group。一个 partition 和一个消费组中一个消费者绑定（保证partition 内消息的有序性），每一条该 partition 上消息是被投递到订阅了该 topic 的 comsumer group 上，交由组内的这个 comsumer 实例进行消费。当所有的 comsumer 都在同一个 group中时，这就变成了”队列模式“，而当每个 comsumer group 中都只有一个 comsumer 时，这就又变成了”发布-订阅模式“。实际上， kafka 这种消费者组的模式仍然属于发布-订阅模式范畴，只是订阅者由单个的消费者实例变成了消费者组。
Kafka的设计理念之一就是同时提供离线处理和实时处理，而 comsumer group 的这种设计就能够满足这种特性，为消息的多元化处理提供了支持。它既能够提供以分区为粒度的并行能力，同时又能保证消息在分区内的有序性。比如，我们可以使用Storm这种实时流处理系统对消息进行实时在线处理，同时使用Hadoop这种批处理系统进行离线处理，还可以同时将数据实时备份到另一 个数据中心，只需要保证这三个操作所使用的consumer在不同的consumer group即可。
如对本文有疑问，
点击进行留言回复！！
我要评论
网友评论