【大数据项目学习】第十一章：Kafka消息系统

第十一章：Kafka消息系统

一个初学者的大数据学习过程

---

---

1. Kafka是什么

kafka是LinkedIn开发并开源的一个分布式MQ系统，现在是Apache的一个孵化项目。在它的主页描述kafka为一个高吞吐量的分布式（能将消息分散到不同的节点上）MQ。Kafka仅仅由7000行Scala编写，据了解，Kafka每秒可以生产约25万消息（50 MB），每秒处理55万消息（110 MB）。目前越来越多的开源分布式处理系统如Cloudera、Apache Storm、Spark都支持与Kafka集成。

2. Kafka在Linked In的应用

LinkedIn的工程师团队已经把Kafka打造为管理信息流的开源解决方案。他们把Kafka作为消息中枢，帮助公司的各个应用以松耦合的方式在一起工作。LinkedIn已经严重依赖于kafka，并且基于Kafka的生态系统，LinkedIn开发出了一些开源组件和公司内部组件。Kafka在LinkedIn中的应用场景如下所述：

1. 系统监控：LinkedIn内所有的主机都会往Kafka发送系统健康信息和运行信息，负责展示运维信息和报警的
   系统，则从Kafka订阅获取这些运维信息，处理后进行业务的展示和告警业务的触发。更进一步，LinkedIn
   通过自家的实时流处理系统Samza对这些运维数据进行实时的处理分析，生成实时的调用图分析。
2. 传统的消息队列：LinkedIn内大量的应用系统把Kafka作为一个分布式消息队列进行使用。这些应用囊括了搜索、内容相关性反馈等应用。这些应用将处理后的数据通过Kafka传递到Voldemort分布式存储系统。
3. 分析：LinkedIn会搜索所有的数据以更好地了解用户是如何使用LinkedIn产品的。哪些网页被浏览，哪些内容被点击这样的信息都会发送到每个数据中心的Kafka。这些数据被汇总起来并通过Kafka发送到Hadoop集群进行分析和每日报表生成。

3. Kafka设计目标

kafka作为一种分布式的、基于发布/订阅的消息系统，其主要设计目标如下：

1. 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上的数据也能保证常数时
   间的访问性能。
2. 高吞吐率，即使在非常廉价的商用机器上也能做到单机支持每秒100k条的消息的传输。
3. 支持Kafka Server间的消息分区，以及分布式消费，同时保证每个分区内的消息顺序传输。
4. 支持离线数据处理和实时数据处理。
5. 支持在线水平扩展。

4. Kafka特点

1. 高性能、高吞吐量
   单节点支持上千个客户端，每秒钟有上百M（百万级）的吞吐，基本上达到了网卡的极限
2. 持久性
   Kafka消息直接持久化到普通磁盘，性能非常好，而且数据不会丢失，数据会顺序写，消费的数据也会顺序读，持久化的同时还保证了数据的读写顺序。
3. 分布式
   基于分布式的扩展、和容错机制；Kafka的数据都会复制到几台服务器上。当某一台故障失效时，生产者和
   消费者转而使用其它的机器。
4. 灵活性
   消息长时间持久化到磁盘，client维护消费的状态，因此非常的灵活。原因一：消息持久化数据时间跨度比较长，可以设置为一天、一周或者更长 原因二：消息的状态自己维护，消费到哪里自己知道。

5. Kafka在生态圈中的位置

6. Kafka系统架构组成

在Kafka集群中生产者将消息发送给以Topic命名的消息队列Queue中，消费者订阅发往某个Topic命名的消息队列Queue中的消息。其中Kafka集群由若干个Broker组成，Topic由若干个Partition组成，每个Partition里面的消息通过Offset来获取。

6.1 Broker

一台Kafka服务器就是一个Broker，一个集群由多个Broker组成，一个Broker可以容纳多个Topic，Broker和Broker之间没有Master和Standby的概念，它们之间的地位基本是平等的。

6.2. Topic

每条发送到Kafka集群的消息都属于某个主题，这个主题就称为Topic。物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存在一个或多个Broker上，但是用户只需指定消息的主题Topic即可生产或者消费数据而不需要去关心数据存放在何处。

6.3. Partition

为了实现可扩展性，一个Topic可以被分为多个Partition，从而分布到多台Broker上。Partition中的每条消息都会被分配一个自增Id（Offset）。Kafka只保证按一个Partition中的顺序将消息发送给消费者，但是不保证单个Topic中的多个Partition之间的顺序。

6.4 Offset

消息在Topic的Partition中的位置，同一个Partition中的消息随着消息的写入，其对应的Offset
也自增，其内部实现原理如下图所示。

6.5 Replica

副本。Topic的Partition含有N个Replica，N为副本因子。其中一个Replica为Leader，其他都为Follower，Leader处理Partition的所有读写请求，与此同时，Follower会定期地去同步Leader上的数据。

6.6 Message

消息，是通信的基本单位。每个Producer可以向一个Topic（主题）发布一些消息。

6.7 Producer

消息生产者，即将消息发布到指定的Topic中，同时Producer也能决定此消息所属的Partition：比如基于Round-Robin（轮询）方式或者Hash（哈希）方式等一些算法。

6.8 Consumer：

消息消费者，即向指定的Topic获取消息，根据指定Topic的分区索引及其对应分区上的消息偏移量来获取消息。

6.9 Consumer Group

消费者组，每个Consumer属于一个Consumer Group；反过来，每个Consumer Group中可以包含多个Consumer。如果所有的Consumer都具有相同的Consumer Group，那么消息将会在Consumer之间进行负载均衡。也就是说一个Partition中的消息只会被相同Consumer Group中的某个Consumer消费，每个Consumer Group消息消费是相互独立的。

6.10 Zookeeper

存放Kafka集群相关元数据的组件。在Zookeeper集群中会保存Topic的状态信息，例
如分区的个数、分区的组成、分区的分别情况等。保存Broker的状态信息；保存消费
者的消费信息等。通过这些信息，Kafka很好地将消息生产、消息存储、消息消费的过
程结合起来。

7. Kafka拓扑结构

一个典型的Kafka集群中包含若干个Producer（可以是某个模块下，发的Command，或者是Web前端产生Page View，或者是服务器日志等），若干个Broker（Kafka集群支持水平扩展，一般Broker数量越多，整个Kafka集群的吞吐率也就越高），若干个Consumer Group，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置。Producer使用push模式将消息发布到Broker上，Consumer 使用pull模式从Broker上订阅并消费消息。

一个简单的消息发送流程如下所示。

1. Producer根据指定的路由方法（Round-Robin、Hash等），将消息Push到Topic的某个Partition里面。
2. Kafka集群接收到Producer发过来的消息后，将其持久化到磁盘，并保留消息指定时长（可配置），而不关注消息是否被消费。
3. Consumer从Kafka集群Pull数据，并控制获取消息的Offset。

ZooKeeper用于管理、协调Kafka代理。

1. Broker注册
   Broker在zookeeper中保存为一个临时节点，节点的路径是/brokers/ids/[brokerid],每个节点会保存对应broker的IP以及端口等信息。
2. Topic注册
   在kafka中,一个topic会被分成多个区并被分到多个broker上，分区的信息以及broker的分布情况都保存在zookeeper中，根节点路径为/brokers/topics,每个topic都会在topics下建立独立的子节点，每个topic节点下都会包含分区以及broker的对应信息。
3. 生产者负载均衡
   当Broker启动时，会注册该Broker的信息，以及可订阅的topic信息。生产者通过注册在Broker以及Topic上的watcher动态的感知Broker以及Topic的分区情况，从而将Topic的分区动态的分配到broker上。