Storm上游数据源之Kakfa

1、Kafka是什么

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

 

KAFKA + STORM +REDIS

 

1. Apache Kafka是一个开源消息系统，由Scala写成。是由Apache软件基金会开发的一个开源消息系统项目。
2. Kafka最初是由LinkedIn开发，并于2011年初开源。2012年10月从Apache Incubator毕业。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。
3. Kafka是一个分布式消息队列：生产者、消费者的功能。它提供了类似于JMS的特性，但是在设计实现上完全不同，此外它并不是JMS规范的实现。
4. Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer,消息接受者称为Consumer,此外kafka集群有多个kafka实例组成，每个实例(server)成为broker。
5. 无论是kafka集群，还是producer和consumer都依赖于zookeeper集群保存一些meta信息，来保证系统可用性

2、JMS是什么

2.1、JMS的基础

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

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

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

 

jdk，kafka，activemq……

2.2、JMS消息传输模型

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

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

1. 发布/订阅模式（一对多，数据生产后，推送给所有订阅者）

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

 

queue.put（object）  数据生产

queue.take(object)    数据消费

2.3、JMS核心组件

1. Destination：消息发送的目的地，也就是前面说的Queue和Topic。
2. Message [m1] ：从字面上就可以看出是被发送的消息。

1. Producer： 消息的生产者，要发送一个消息，必须通过这个生产者来发送。
2. MessageConsumer： 与生产者相对应，这是消息的消费者或接收者，通过它来接收一个消息。

 

 

通过与ConnectionFactory可以获得一个connection

通过connection可以获得一个session会话。

 

2.4、常见的类JMS消息服务器

2.4.1、JMS消息服务器 ActiveMQ

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

主要特点：

1. 多种语言和协议编写客户端。语言: Java, C, C++, C#, Ruby, Perl, Python, PHP。应用协议: OpenWire,Stomp REST,WS Notification,XMPP,AMQP
2. 完全支持JMS1.1和J2EE 1.4规范 (持久化,XA消息,事务)
3. 对Spring的支持,ActiveMQ可以很容易内嵌到使用Spring的系统里面去,而且也支持Spring2.0的特性
4. 通过了常见J2EE服务器(如 Geronimo,JBoss 4, GlassFish,WebLogic)的测试,其中通过JCA 1.5 resource adaptors的配置,可以让ActiveMQ可以自动的部署到任何兼容J2EE 1.4 商业服务器上
5. 支持多种传送协议:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
6. 支持通过JDBC和journal提供高速的消息持久化
7. 从设计上保证了高性能的集群,客户端-服务器,点对点
8. 支持Ajax
9. 支持与Axis的整合
10. 可以很容易得调用内嵌JMS provider,进行测试

2.4.2、分布式消息中间件 Metamorphosis

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

主要特点：

1. 生产者、服务器和消费者都可分布
2. 消息存储顺序写
3. 性能极高,吞吐量大
4. 支持消息顺序
5. 支持本地和XA事务
6. 客户端pull，随机读,利用sendfile系统调用，zero-copy ,批量拉数据
7. 支持消费端事务
8. 支持消息广播模式
9. 支持异步发送消息
10. 支持http协议
11. 支持消息重试和recover
12. 数据迁移、扩容对用户透明
13. 消费状态保存在客户端
14. 支持同步和异步复制两种HA
15. 支持group commit

2.4.3、分布式消息中间件 RocketMQ

RocketMQ 是一款分布式、队列模型的消息中间件，具有以下特点：

1. 能够保证严格的消息顺序
2. 提供丰富的消息拉取模式
3. 高效的订阅者水平扩展能力
4. 实时的消息订阅机制
5. 亿级消息堆积能力
6. Metaq3.0 版本改名，产品名称改为RocketMQ

2.4.4、其他MQ

1. .NET消息中间件 DotNetMQ
2. 基于HBase的消息队列 HQueue
3. Go 的 MQ 框架 KiteQ
4. AMQP消息服务器 RabbitMQ
5. MemcacheQ 是一个基于 MemcacheDB 的消息队列服务器。

 

 

3、为什么需要消息队列（重要）

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

以用户注册的案列来说明消息系统的作用

3.1、用户注册的一般流程

 

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

3.2、用户注册的并行执行

 

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

 

3.3、用户注册的最终一致

 

1. 保证主流程的正常执行、执行成功之后，发送MQ消息出去。
2. 需要这个destination的其他系统通过消费数据再执行，最终一致。

 

4、Kafka核心组件

1. Topic ：消息根据Topic进行归类
2. Producer：发送消息者
3. Consumer：消息接受者
4. broker：每个kafka实例(server)
5. Zookeeper：依赖集群保存meta信息。

 

5、Kafka集群部署

5.1集群部署的基本流程

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

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

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

1. 关闭防火墙

chkconfig iptables off  && setenforce 0

1. 创建用户

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

1. 创建工作目录并赋权

mkdir /export

mkdir /export/servers

chmod 755 -R /export

1. 切换到realtime用户下

su realtime

5.3 Kafka集群部署

5.3.1、下载安装包

Apache Kafka

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

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

5.3.2、解压安装包

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.3、修改配置文件

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

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

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

输入以下内容：

 

5.3.4、分发安装包

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.5、再次修改配置文件（重要）

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

5.3.6、启动集群

依次在各节点上启动kafka

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

 

5.4、Kafka常用操作命令

1. 查看当前服务器中的所有topic

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

1. 创建topic

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

1. 删除topic

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

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

1. 通过shell命令发送消息

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

1. 通过shell消费消息

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

1. 查看消费位置

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

1. 查看某个Topic的详情

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

 

6、Kafka生产者Java API

 

7、Kafka消费者Java API

 

---

 

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

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

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

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

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

XMLMessage:  一个XML类型的消息。

最常用的是TextMessage和ObjectMessage。

 

1、Kafka整体结构图

Kafka名词解释和工作方式

 

1. Producer ：消息生产者，就是向kafka broker发消息的客户端。
2. Consumer ：消息消费者，向kafka broker取消息的客户端
3. Topic ：咋们可以理解为一个队列。
4. Consumer Group （CG）：这是kafka用来实现一个topic消息的广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。一个topic可以有多个CG。topic的消息会复制（不是真的复制，是概念上的）到所有的CG，但每个partion只会把消息发给该CG中的一个consumer。如果需要实现广播，只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。
5. Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。
6. Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。
7. Offset：kafka的存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如你想找位于2049的位置，只要找到2048.kafka的文件即可。当然the first offset就是00000000000.kafka

2、Consumer与topic关系

本质上kafka只支持Topic；

1. 每个group中可以有多个consumer，每个consumer属于一个consumer group；

通常情况下，一个group中会包含多个consumer，这样不仅可以提高topic中消息的并发消费能力，而且还能提高"故障容错"性，如果group中的某个consumer失效那么其消费的partitions将会有其他consumer自动接管。

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

那么一个group中所有的consumer将会交错的消费整个Topic，每个group中consumer消息消费互相独立，我们可以认为一个group是一个"订阅"者。

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

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

1. kafka的设计原理决定,对于一个topic，同一个group中不能有多于partitions个数的consumer同时消费，否则将意味着某些consumer将无法得到消息。

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

3、Kafka消息的分发

         Producer客户端负责消息的分发

1. 1. kafka集群中的任何一个broker都可以向producer提供metadata信息,这些metadata中包含"集群中存活的servers列表"/"partitions leader列表"等信息；
   2. 当producer获取到metadata信息之后, producer将会和Topic下所有partition leader保持socket连接；
   3. 消息由producer直接通过socket发送到broker，中间不会经过任何"路由层"，事实上，消息被路由到哪个partition上由producer客户端决定；

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

1. 在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的并发消费能力，步骤如下：

1. 假如topic1,具有如下partitions: P0,P1,P2,P3
2. 加入group中,有如下consumer: C1,C2
3. 首先根据partition索引号对partitions排序: P0,P1,P2,P3
4. 根据consumer.id排序: C0,C1
5. 计算倍数: M = [P0,P1,P2,P3].size / [C0,C1].size,本例值M=2(向上取整)
6. 然后依次分配partitions: C0 = [P0,P1],C1=[P2,P3],即Ci = [P(i * M),P((i + 1) * M -1)]

 

5、kafka文件存储机制

5.1、Kafka文件存储基本结构

1. 在Kafka文件存储中，同一个topic下有多个不同partition，每个partition为一个目录，partiton命名规则为topic名称+有序序号，第一个partiton序号从0开始，序号最大值为partitions数量减1。
2. 每个partion(目录)相当于一个巨型文件被平均分配到多个大小相等segment(段)数据文件中。但每个段segment file消息数量不一定相等，这种特性方便old segment file快速被删除。默认保留7天的数据。

 

1. 每个partiton只需要支持顺序读写就行了，segment文件生命周期由服务端配置参数决定。（什么时候创建，什么时候删除）

 

数据有序的讨论？

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

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

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

 

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

5.2、Kafka Partition Segment

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

 

1. Segment文件命名规则：partion全局的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset值。数值最大为64位long大小，19位数字字符长度，没有数字用0填充。
2. 索引文件存储大量元数据，数据文件存储大量消息，索引文件中元数据指向对应数据文件中message的物理偏移地址。

 

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

 

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

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

 

1. segment data file由许多message组成， qq物理结构如下：

 

 

5.3、Kafka 查找message

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

        

 

 

5.3.1、查找segment file

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

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

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

其他后续文件依次类推。

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

5.3.2、通过segment file查找message

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

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

1、Redis概述

1. Redis是一个开源，先进的key-value存储，并用于构建高性能，可扩展的应用程序的完美解决方案。
2. Redis从它的许多竞争继承来的三个主要特点：
3. Redis数据库完全在内存中，使用磁盘仅用于持久性。
4. 相比许多键值数据存储，Redis拥有一套较为丰富的数据类型。String，List,set,map,sortSet
5. Redis可以将数据复制到任意数量的从服务器。

2、Redis 优势

1. 异常快速：Redis的速度非常快，每秒能执行约11万集合，每秒约81000+条记录。
2. 支持丰富的数据类型：Redis支持字符串、列表、集合、有序集合散列数据类型，这使得它非常容易解决各种各样的问题。
3. 操作都是原子性：所有Redis操作是原子的，这保证了如果两个客户端同时访问的Redis服务器将获得更新后的值。----计数器
4. 多功能实用工具：Redis是一个多实用的工具，可以在多个用例如缓存，消息，队列使用(Redis原生支持发布/订阅)，任何短暂的数据，应用程序，如Web应用程序会话，网页命中计数等。

3、Redis安装部署

3.1、Redis下载、编译、安装

1. 下载redis3.0.5

                  wget http://download.redis.io/releases/redis-3.0.5.tar.gz

1. 解压文件，并创建软件连接

                  tar -zxvf  redis-3.0.5.tar.gz -C /export/servers/

                  ln  –s  redis-3.0.5/  redis

1. 编译redis源码

                  cd /export/servers/redis

                  make（先安装gcc）

1. 将编译后的可执行文件安装到/user/local/redis

                  make PREFIX=/usr/local/redis install

3.2、启动Redis

1. 启动方式一：Redis前台默认启动

进入redis安装目录，并启动Redis服务

                            cd /usr/local/redis/bin/

                            ./redis-server

1. 启动方式二：Redis使用配置文件启动

拷贝源码中的redis.conf文件到redis的安装目录

                           cp /export/servers/redis/redis.conf        /usr/local/redis/

修改redis.conf的属性

                           daemonize no  è daemonize yes

启动redis服务

                            cd  /usr/local/redis

                             bin/redis-server    ./redis.conf

3.3、日志文件及持久化文件配置

1. 修改生成默认日志文件位置

                  logfile "/usr/local/redis/logs/redis.log"

1. 配置持久化文件存放位置

                 dir /usr/local/redis/data/redisData

3.4、Redis客户端使用

         <dependency>

         <groupId>redis.clients</groupId>

         <artifactId>jedis</artifactId>

         <version>2.8.0</version>

         </dependency>

        

 

4、Redis持久化

有两种持久化方案：RDB和AOF

1. RDB方式按照一定的时间间隔对数据集创建基于时间点的快照。

                  2）AOF方式记录Server收到的写操作到日志文件，在Server重启时通过回放这些写操作来重建数据集。该方式类似于MySQL中基于语句格式的binlog。当日志变大时Redis可在后台重写日志。

1. AOF持久化配置

                  1）修改redis.config配置文件，找到appendonly。默认是appendonly no。改成appendonly yes

                  2）再找到appendfsync 。默认是 appendfsync everysec

                            appendfsync always  

                           #每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用  

                            appendfsync everysec    

                             #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐  

                            appendfsync no    

                            #完全依赖os，性能最好,持久化没保证  

1. RDB持久化配置

         默认情况下，Redis保存数据集快照到磁盘，名为dump.rdb的二进制文件。可以设置让Redis在N秒内至少有M次数据集改动时保存数据集，或者你也可以手动调用SAVE或者BGSAVE命令。 
例如，这个配置会让Redis在每个60秒内至少有1000次键改动时自动转储数据集到磁盘

         save 60 1000 

 

 

5、Redis数据结构