Kafka集群安装部署、Kafka生产者、Kafka消费者

Storm上游数据源之Kakfa

目标：

理解Storm消费的数据来源、理解JMS规范、理解Kafka核心组件、掌握Kakfa生产者API、掌握Kafka消费者API。对流式计算的生态环境有深刻的了解，具有流式计算项目架构的能力。

大纲：

一、  kafka是什么？

二、  JMS规范是什么？

三、  为何须要消息队列？

四、  Kafka核心组件

五、  Kafka安装部署

六、  Kafka生产者Java API

七、  Kafka消费者Java API

内容

一、Kafka是什么

在流式计算中，Kafka通常用来缓存数据，Storm经过消费Kafka的数据进行计算。

KAFKA + STORM +REDIS

l  Apache Kafka是一个开源消息系统，由Scala写成。是由Apache软件基金会开发的一个开源消息系统项目。

l  Kafka最初是由LinkedIn开发，并于2011年初开源。2012年10月从Apache Incubator毕业。该项目的目标是为处理实时数据提供一个统1、高通量、低等待的平台。

l  Kafka是一个分布式消息队列：生产者、消费者的功能。它提供了相似于JMS的特性，可是在设计实现上彻底不一样，此外它并非JMS规范的实现。

l  Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer,消息接受者称为Consumer,此外kafka集群有多个kafka实例组成，每一个实例(server)成为broker。

l  不管是kafka集群，仍是producer和consumer都依赖于zookeeper集群保存一些meta信息，来保证系统可用性

二、JMS是什么

2.一、JMS的基础

         JMS是什么：JMS是Java提供的一套技术规范

JMS干什么用：用来异构系统 集成通讯，缓解系统瓶颈，提升系统的伸缩性加强系统用户体验，使得系统模块化和组件化变得可行并更加灵活

经过什么方式：生产消费者模式（生产者、服务器、消费者）

 

jdk，kafka，activemq……

2.二、JMS消息传输模型

l  点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）

点对点模型一般是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特色是发送到队列的消息被一个且只有一个接收者接收处理，即便有多个消息监听者也是如此。

l  发布/订阅模式（一对多，数据生产后，推送给全部订阅者）

发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型能够有多种不一样的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的全部消息，即时当前订阅者不可用，处于离线状态。

 

queue.put（object）  数据生产

queue.take(object)    数据消费

2.三、JMS核心组件

l  Destination：消息发送的目的地，也就是前面说的Queue和Topic。

l  Message [m1] ：从字面上就能够看出是被发送的消息。

l  Producer： 消息的生产者，要发送一个消息，必须经过这个生产者来发送。

l  MessageConsumer： 与生产者相对应，这是消息的消费者或接收者，经过它来接收一个消息。

 

经过与ConnectionFactory能够得到一个connection

经过connection能够得到一个session会话。 

2.四、常见的类JMS消息服务器

2.4.一、JMS消息服务器 ActiveMQ

ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个彻底支持JMS1.1和J2EE 1.4规范的。

主要特色：

l  多种语言和协议编写客户端。语言: Java, C, C++, C#, Ruby, Perl, Python, PHP。应用协议: OpenWire,Stomp REST,WS Notification,XMPP,AMQP

l  彻底支持JMS1.1和J2EE 1.4规范 (持久化,XA消息,事务)

l  对Spring的支持,ActiveMQ能够很容易内嵌到使用Spring的系统里面去,并且也支持Spring2.0的特性

l  经过了常见J2EE服务器(如 Geronimo,JBoss 4, GlassFish,WebLogic)的测试,其中经过JCA 1.5 resource adaptors的配置,可让ActiveMQ能够自动的部署到任何兼容J2EE 1.4 商业服务器上

l  支持多种传送协议:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA

l  支持经过JDBC和journal提供高速的消息持久化

l  从设计上保证了高性能的集群,客户端-服务器,点对点

l  支持Ajax

l  支持与Axis的整合

l  能够很容易得调用内嵌JMS provider,进行测试

2.4.二、分布式消息中间件 Metamorphosis

Metamorphosis (MetaQ) 是一个高性能、高可用、可扩展的分布式消息中间件，相似于LinkedIn的Kafka，具备消息存储顺序写、吞吐量大和支持本地和XA事务等特性，适用于大吞吐量、顺序消息、广播和日志数据传输等场景，在淘宝和支付宝有着普遍的应用，现已开源。

主要特色：

l  生产者、服务器和消费者均可分布

l  消息存储顺序写

l  性能极高,吞吐量大

l  支持消息顺序

l  支持本地和XA事务

l  客户端pull，随机读,利用sendfile系统调用，zero-copy ,批量拉数据

l  支持消费端事务

l  支持消息广播模式

l  支持异步发送消息

l  支持http协议

l  支持消息重试和recover

l  数据迁移、扩容对用户透明

l  消费状态保存在客户端

l  支持同步和异步复制两种HA

l  支持group commit

2.4.三、分布式消息中间件 RocketMQ

RocketMQ 是一款分布式、队列模型的消息中间件，具备如下特色：

l  可以保证严格的消息顺序

l  提供丰富的消息拉取模式

l  高效的订阅者水平扩展能力

l  实时的消息订阅机制

l  亿级消息堆积能力

l  Metaq3.0 版本更名，产品名称改成RocketMQ

2.4.四、其余MQ

l  .NET消息中间件 DotNetMQ

l  基于HBase的消息队列 HQueue

l  Go 的 MQ 框架 KiteQ

l  AMQP消息服务器 RabbitMQ

l  MemcacheQ 是一个基于 MemcacheDB 的消息队列服务器。

三、为何须要消息队列（重要）

消息系统的核心做用就是三点：解耦，异步和并行

以用户注册的案列来讲明消息系统的做用

3.一、用户注册的通常流程

 

问题：随着后端流程愈来愈多，每步流程都须要额外的耗费不少时间，从而会致使用户更长的等待延迟。

3.二、用户注册的并行执行

 

问题：系统并行的发起了4个请求，4个请求中，若是某一个环节执行1分钟，其余环节再快，用户也须要等待1分钟。若是其中一个环节异常以后，整个服务挂掉了。

3.三、用户注册的最终一致

 

一、  保证主流程的正常执行、执行成功以后，发送MQ消息出去。

二、  须要这个destination的其余系统经过消费数据再执行，最终一致。

 

四、Kafka核心组件

l  Topic ：消息根据Topic进行归类

l  Producer：发送消息者

l  Consumer：消息接受者

l  broker：每一个kafka实例(server)

l  Zookeeper：依赖集群保存meta信息。

 

五、Kafka集群部署

5.1集群部署的基本流程

下载安装包、解压安装包、修改配置文件、分发安装包、启动集群

5.2集群部署的基础环境准备

安装前的准备工做（zk集群已经部署完毕）

l  关闭防火墙

chkconfig iptables off  && setenforce 0

l  建立用户

groupadd realtime &&　useradd realtime　&& usermod -a -G realtime realtime

l  建立工做目录并赋权

mkdir /export

mkdir /export/servers

chmod 755 -R /export

l  切换到realtime用户下

su realtime

5.3 Kafka集群部署

5.3.一、下载安装包

http://kafka.apache.org/downloads.html

在linux中使用wget命令下载安装包

        wget http://mirrors.hust.edu.cn/apache/kafka/0.8.2.2/kafka_2.11-0.8.2.2.tgz

5.3.二、解压安装包

tar -zxvf /export/software/kafka_2.11-0.8.2.2.tgz -C /export/servers/

cd /export/servers/

ln -s kafka_2.11-0.8.2.2 kafka

5.3.三、修改配置文件

cp   /export/servers/kafka/config/server.properties

/export/servers/kafka/config/server.properties.bak

vi  /export/servers/kafka/config/server.properties

输入如下内容：

 

5.3.四、分发安装包

scp -r /export/servers/kafka_2.11-0.8.2.2 kafka02:/export/servers

而后分别在各机器上建立软连

cd /export/servers/

ln -s kafka_2.11-0.8.2.2 kafka

5.3.五、再次修改配置文件（重要）

依次修改各服务器上配置文件的的broker.id，分别是0,1,2不得重复。

5.3.六、启动集群

首先启动zookeeper集群

zkServer.sh start

依次在各节点上启动kafka

bin/kafka-server-start.sh  config/server.properties

 

集群启动后会卡主页面，须要再开一个窗口调用jps指令查看kafka是否已经启动

 

5.四、Kafka经常使用操做命令

l  查看当前服务器中的全部topic

bin/kafka-topics.sh --list --zookeeper  zk01:2181

l  建立topic

./kafka-topics.sh --create --zookeeper mini1:2181 --replication-factor 1 --partitions 3 --topic first

l  删除topic

sh bin/kafka-topics.sh --delete --zookeeper zk01:2181 --topic test

须要server.properties中设置delete.topic.enable=true不然只是标记删除或者直接重启。

l  经过shell命令发送消息

kafka-console-producer.sh --broker-list kafka01:9092 --topic itheima

l  经过shell消费消息

sh bin/kafka-console-consumer.sh --zookeeper zk01:2181 --from-beginning --topic test1

l  查看消费位置

sh kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --zookeeper zk01:2181 --group testGroup

l  查看某个Topic的详情

sh kafka-topics.sh --topic test --describe --zookeeper zk01:2181

六、Kafka生产者Java API

 

七、Kafka消费者Java API

 

---

 

StreamMessage：Java 数据流消息，用标准流操做来顺序的填充和读取。

MapMessage：一个Map类型的消息；名称为 string 类型，而值为 Java 的基本类型。

TextMessage：普通字符串消息，包含一个String。

ObjectMessage：对象消息，包含一个可序列化的Java 对象

BytesMessage：二进制数组消息，包含一个byte[]。

XMLMessage:  一个XML类型的消息。

最经常使用的是TextMessage和ObjectMessage。

 

Kafka负载均衡、Kafka自定义Partition、Kafk文件存储机制介绍

名称：

         Kafka技术加强

         注：请先学习Kafka基础

目标：

     经过本模块的学习，可以掌握Kafka的负载均衡、Producer生产数据、Kafka文件存储机制、Kafka自定义partition

课程大纲：

一、  Kafka总体结构图

二、  Consumer与topic关系

三、  Kafka  Producer消息分发

四、  Consumer 的负载均衡

五、  Kafka文件存储机制

内容

一、Kafka总体结构图

Kafka名词解释和工做方式

l  Producer ：消息生产者，就是向kafka broker发消息的客户端。

l  Consumer ：消息消费者，向kafka broker取消息的客户端

l  Topic ：我们能够理解为一个队列。目标发送的目的地，这是一个逻辑上的概念，落到磁盘上是一个partition的目录。

partition的目录中有多个segment组合(index,log)；一个Topic对应多个partition[0,1,2,3]，一个partition对应多个segment组合。一个segment有默认的大小是1G。每一个partition能够设置多个副本(replication-factor 1),会从全部的副本中选取一个leader出来。全部读写操做都是经过leader来进行的。

特别强调，和mysql中主从有区别，mysql作主从是为了读写分离，在kafka中读写操做都是leader。

l  Consumer Group （CG）：这是kafka用来实现一个topic消息的广播（发给全部的consumer）和单播（发给任意一个consumer）的手段。一个topic能够有多个CG。topic的消息会复制（不是真的复制，是概念上的）到全部的CG，但每一个partion只会把消息发给该CG中的一个consumer。若是须要实现广播，只要每一个consumer有一个独立的CG就能够了。要实现单播只要全部的consumer在同一个CG。用CG还能够将consumer进行自由的分组而不须要屡次发送消息到不一样的topic。

l  Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker能够容纳多个topic。

l  Partition：为了实现扩展性，一个很是大的topic能够分布到多个broker（即服务器）上，一个topic能够分为多个partition，每一个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的总体（多个partition间）的顺序。

l  Offset：kafka的存储文件都是按照offset.kafka来命名，用offset作名字的好处是方便查找。例如你想找位于2049的位置，只要找到2048.kafka的文件便可。固然the first offset就是00000000000.kafka

二、Consumer与topic关系

本质上kafka只支持Topic；

l  每一个group中能够有多个consumer，每一个consumer属于一个consumer group；

一般状况下，一个group中会包含多个consumer，这样不只能够提升topic中消息的并发消费能力，并且还能提升"故障容错"性，若是group中的某个consumer失效那么其消费的partitions将会有其余consumer自动接管。

l  对于Topic中的一条特定的消息，只会被订阅此Topic的每一个group中的其中一个consumer消费，此消息不会发送给一个group的多个consumer；

那么一个group中全部的consumer将会交错的消费整个Topic，每一个group中consumer消息消费互相独立，咱们能够认为一个group是一个"订阅"者。

l  在kafka中,一个partition中的消息只会被group中的一个consumer消费(同一时刻)；

一个Topic中的每一个partions，只会被一个"订阅者"中的一个consumer消费，不过一个consumer能够同时消费多个partitions中的消息。

l  kafka的设计原理决定,对于一个topic，同一个group中不能有多于partitions个数的consumer同时消费，不然将意味着某些consumer将没法获得消息。

kafka只能保证一个partition中的消息被某个consumer消费时是顺序的；事实上，从Topic角度来讲,当有多个partitions时,消息仍不是全局有序的。

三、Kafka消息的分发

         Producer客户端负责消息的分发

l  kafka集群中的任何一个broker均可以向producer提供metadata信息,这些metadata中包含"集群中存活的servers列表"/"partitions leader列表"等信息；

l  当producer获取到metadata信息以后, producer将会和Topic下全部partition leader保持socket链接；

l  消息由producer直接经过socket发送到broker，中间不会通过任何"路由层"，事实上，消息被路由到哪一个partition上由producer客户端决定；

好比能够采用"random""key-hash""轮询"等,若是一个topic中有多个partitions,那么在producer端实现"消息均衡分发"是必要的。

l  在producer端的配置文件中,开发者能够指定partition路由的方式。

Producer消息发送的应答机制

设置发送数据是否须要服务端的反馈,有三个值0,1,-1

0: producer不会等待broker发送ack

1: 当leader接收到消息以后发送ack

-1: 当全部的follower都同步消息成功后发送ack

         request.required.acks=0

4、Consumer的负载均衡

当一个group中,有consumer加入或者离开时,会触发partitions均衡.均衡的最终目的,是提高topic的并发消费能力，步骤以下：

一、    假如topic1,具备以下partitions: P0,P1,P2,P3

二、    加入group中,有以下consumer: C1,C2

三、    首先根据partition索引号对partitions排序: P0,P1,P2,P3

四、    根据consumer.id排序: C0,C1

五、    计算倍数: M = [P0,P1,P2,P3].size / [C0,C1].size,本例值M=2(向上取整)

六、    而后依次分配partitions: C0 = [P0,P1],C1=[P2,P3],即Ci = [P(i * M),P((i + 1) * M -1)]

 

五、kafka文件存储机制

5.一、Kafka文件存储基本结构

l  在Kafka文件存储中，同一个topic下有多个不一样partition，每一个partition为一个目录，partiton命名规则为topic名称+有序序号，第一个partiton序号从0开始，序号最大值为partitions数量减1。

l  每一个partion(目录)至关于一个巨型文件被平均分配到多个大小相等segment(段)数据文件中。但每一个段segment file消息数量不必定相等，这种特性方便old segment file快速被删除。默认保留7天的数据。

l  每一个partiton只须要支持顺序读写就好了，segment文件生命周期由服务端配置参数决定。（何时建立，何时删除）

数据有序的讨论？

         一个partition的数据是不是有序的？          间隔性有序，不连续

         针对一个topic里面的数据，只能作到partition内部有序，不能作到全局有序。

         特别加入消费者的场景后，如何保证消费者消费的数据全局有序的？伪命题。

只有一种状况下才能保证全局有序？就是只有一个partition。

5.二、Kafka Partition Segment

l  Segment file组成：由2大部分组成，分别为index file和data file，此2个文件一一对应，成对出现，后缀".index"和“.log”分别表示为segment索引文件、数据文件。

 

l  Segment文件命名规则：partion全局的第一个segment从0开始，后续每一个segment文件名为上一个segment文件最后一条消息的offset值。数值最大为64位long大小，19位数字字符长度，没有数字用0填充。

l  索引文件存储大量元数据，数据文件存储大量消息，索引文件中元数据指向对应数据文件中message的物理偏移地址。

 

3，497：当前log文件中的第几条信息，存放在磁盘上的那个地方

 

上述图中索引文件存储大量元数据，数据文件存储大量消息，索引文件中元数据指向对应数据文件中message的物理偏移地址。

其中以索引文件中元数据3,497为例，依次在数据文件中表示第3个message(在全局partiton表示第368772个message)、以及该消息的物理偏移地址为497。 

l  segment data file由许多message组成， qq物理结构以下：

关键字	解释说明
8 byte offset	在parition(分区)内的每条消息都有一个有序的id号，这个id号被称为偏移(offset),它能够惟一肯定每条消息在parition(分区)内的位置。即offset表示partiion的第多少message
4 byte message size	message大小
4 byte CRC32	用crc32校验message
1 byte “magic"	表示本次发布Kafka服务程序协议版本号
1 byte “attributes"	表示为独立版本、或标识压缩类型、或编码类型。
4 byte key length	表示key的长度,当key为-1时，K byte key字段不填
K byte key	可选
value bytes payload	表示实际消息数据。

 

 

5.三、Kafka 查找message

读取offset=368776的message，须要经过下面2个步骤查找。

5.3.一、查找segment file

00000000000000000000.index表示最开始的文件，起始偏移量(offset)为0

00000000000000368769.index的消息量起始偏移量为368770 = 368769 + 1

00000000000000737337.index的起始偏移量为737338=737337 + 1

其余后续文件依次类推。

以起始偏移量命名并排序这些文件，只要根据offset **二分查找**文件列表，就能够快速定位到具体文件。当offset=368776时定位到00000000000000368769.index和对应log文件。

5.3.二、经过segment file查找message

当offset=368776时，依次定位到00000000000000368769.index的元数据物理位置和00000000000000368769.log的物理偏移地址

而后再经过00000000000000368769.log顺序查找直到offset=368776为止。

六、Kafka自定义Partition

         见代码