云应用开发类企业案例 Kafka简介 Kafka简介.docxVIP

PAGE7 / NUMPAGES8 Kafka简介 Kafka 简介 摘 要：本章节主要讲解Apache Kafka订阅消息系统，其中对Kafka的背景、什么是Kafka以及有哪些应用场景进行详细讲解。 关键词：背景；Kafka；应用场景； 1. Kafka的背景—Apache基金会的顶级项目 Kafka是最初由LinkedIn公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统 kafka作为一个消息系统，早期设计的目的是用作 LinkedIn 的活动流(Activity Stream)和运营数据处理管道(Pipeline)。 活动流数据是所有的网站对用户的使用情况做分析的时候要用到的最常规的部分,活动数据包括页面的访问量(pv)、被查看内容方面的信息以及搜索内容。这种数据通常的处理方式是先把各种活动以日志的形式写入某种文件，然后周期性的对这些文件进行统计分析。 运营数据指的是服务器的性能数据(CPU、IO 使用率、请求时间、服务日志等)。 它是由 LinkedIn 公司开发，使用 Scala 语言编写，之后成为 Apache 基金会的一个顶级项目。 2. 发布与订阅消息系统 2.1. 概念 在正式讨论Apache Kafka之前，先来了解发布与订阅消息系统的概念，并认识这个系统的重要性。数据(消息)的发送者(发布者)不会直接把消息发送给接收者，这是发布与订阅消息系统的一个特点。发布者以某种方式对消息进行分类，接收者(订阅者)订阅它们，以便接收特定类型的消息。这是一个简化的传递过程描述。发布与订阅系统一般会有一个broker，也就是发布消息的中心点。 发布与订阅消息系统的大部分应用场景都是从一个简单的消息队列或一个进程间通信开始的。比如电商系统中，包含会员模块、订单模块、商品模块、推荐模块、配送物流模块等，多个模块(子系统)间涉及消息的传递。最早的应用解决方案就是采用（子系统间）直连方式。使得很多子系统交错复杂 如下图1。 图1 （子系统间）直连 2.2. 队列系统出现 为了解决子系统间直连交错的问题，出现了队列系统。 如图2所示包含了 3 个独立的发布与订阅系统。 图2 队列系统架构3个独立的发布订阅系统 这种方式比直接使用点对点的连接要好得多，但这里有太多重复的地方。你的公司因此要为数据队列维护多个系统，每个系统又有各自的缺陷和不足。而且，接下来可能会有更多的场景需要用到消息系统。此时，你真正需要的是一个单一的集中式系统，它可以用来发布通用类型的数据，其规模可以随着公司业务的增长而增长。这时Kafka登场了。 2.3. Kafka登场 Kafka就是为了解决上述问题而设计的一款基于发布与订阅的消息系统。它一般被称为 “分布式提交日志”或者“分布式流平台”。文件系统或数据库提交日志用来提供所有事务的持久记录 ，通过重放这些日志可以重建系统的状态。同样地，Kafka的数据是按照一定顺序持久化保存的，可以按需读取。此外，Kafka的数据分布在整个系统里，具备数据故障保护和性能伸缩能力。 如图基本架构 图3 Kafka基本架构 1）Broker： kafka的服务器ID，一台机器叫一个Broker Kafka集群包含一个或多个服务器，这种服务器被称为broker。broker端不维护数据的消费状态，提升了性能。直接使用磁盘进行存储，线性读写，速度快：避免了数据在JVM内存和系统内存之间的复制，减少耗性能的创建对象和垃圾回收。 2）Producer 是消息生成的源头，负责生产消息并发送到kafka服务器上 3）Consumer 负责消费kafka服务器上的消息 消息消费者，向Kafka broker读取消息的客户端，consumer从broker拉取(pull)数据并进行处理。 3. Kafka基本描述 消息：Kafka的数据单元被称为消息。把消息看成是数据库里的一个“数据行”或一条“记录”。消息由字节数组组成，所以对于Kafka来说，消息里的数据没有特别的格式或含义。消息可以有一个可选的元数据，也就是键(key)。键也是一个字节数组，与消息一样，对于Kafka来说也没有特殊的含义。 批次：为了提高效率，消息被分批次写入 Kafka。批次就是一组消息，这些消息属于同一个主题(topic)和分区(partition)。如果每一个消息都单独穿行于网络，会导致大量的网络开销，把消息分成批次传输可以减少网络开销。不过，这要在时间延迟和吞吐量之间作出权衡； Kafka的消息通过主题进行分类，主题可以被分为若干个分区，消息以追加的方式写入分区。 如图4所示。 图4 主题和分区 3.1. Tpoic、Partition消息分区、Consumer Group