Flume和Kafka

本文是学习时的自我总结，用于往后温习。若有错误还望谅解，不吝赐教

此处附上部份内容所出博客：http://blog.csdn.net/ymh198816/article/details/51998085

 

Flume+Kafka+Storm+Redis实时分析系统基本架构

1)    整个实时分析系统的架构是

2)    先由电商系统的订单服务器产生订单日志,

3)    而后使用Flume去监听订单日志，

4)    并实时把每一条日志信息抓取下来并存进Kafka消息系统中,

5)    接着由Storm系统消费Kafka中的消息，

6)    同时消费记录由Zookeeper集群管理，这样即便Kafka宕机重启后也能找到上次的消费记录，接着从上次宕机点继续从Kafka的Broker中进行消费。可是因为存在先消费后记录日志或者先记录后消费的非原子操做，若是出现恰好消费完一条消息并还没将信息记录到Zookeeper的时候就宕机的相似问题，或多或少都会存在少许数据丢失或重复消费的问题, 其中一个解决方案就是Kafka的Broker和Zookeeper都部署在同一台机子上。

7)    接下来就是使用用户定义好的Storm Topology去进行日志信息的分析并输出到Redis缓存数据库中(也能够进行持久化)，最后用Web APP去读取Redis中分析后的订单信息并展现给用户。

之因此在Flume和Storm中间加入一层Kafka消息系统，就是由于在高并发的条件下, 订单日志的数据会井喷式增加，若是Storm的消费速度(Storm的实时计算能力那是最快之一,可是也有例外, 并且听说如今Twitter的开源实时计算框架Heron比Storm还要快)慢于日志的产生速度，加上Flume自身的局限性，必然会致使大量数据滞后并丢失，因此加了Kafka消息系统做为数据缓冲区，并且Kafka是基于log File的消息系统，也就是说消息可以持久化在硬盘中，再加上其充分利用Linux的I/O特性,提供了可观的吞吐量。架构中使用Redis做为数据库也是由于在实时的环境下，Redis具备很高的读写速度。

 

Flume和Kafka对比

（1）kafka和flume都是日志系统。kafka是分布式消息中间件，自带存储，提供push和pull存取数据功能。flume分为agent（数据采集器）,collector（数据简单处理和写入）,storage（存储器）三部分，每一部分都是能够定制的。好比agent采用RPC（Thrift-RPC）、text（文件）等，storage指定用hdfs作。

（2）kafka作日志缓存应该是更为合适的，可是 flume的数据采集部分作的很好，能够定制不少数据源，减小开发量。因此比较流行flume+kafka模式，若是为了利用flume写hdfs的能力，也能够采用kafka+flume的方式。

 

Flume

1. Flume是2009年7月开源的日志系统。它内置的各类组件很是齐全，用户几乎没必要进行任何额外开发便可使用。是分布式的日志收集系统，它将各个服务器中的数据收集起来并送到指定的地方去，好比HDFS
2. Flume特色

　　　　1)  可靠性

　　　　当节点出现故障时，日志可以被传送到其余节点上而不会丢失。Flume提供了三种级别的可靠性保障，从强到弱依次分别为：end-to-end（收到数据 agent首先将event写到磁盘上，当数据传送成功后，再删除；若是数据发送失败，能够从新发送），Store on failure（这也是scribe采用的策略，当数据接收方crash时，将数据写到本地，待恢复后，继续发送），Best effort（数据发送到接收方后，不会进行确认）

　　　　2)   可扩展性

　　　　Flume采用了三层架构，分别问agent，collector和storage，每一层都可以水平扩展。其中，全部agent和collector由 master统一管理，这使得系统容易监控和维护，且master容许有多个（使用ZooKeeper进行管理和负载均衡），这就避免了单点故障问题。

　　　　3)   可管理性

　　　　全部agent和colletor由master统一管理，这使得系统便于维护。用户能够在master上查看各个数据源或者数据流执行状况，且能够对各个数据源配置和动态加载。

　　　　4)   功能可扩展性

　　　　用户能够根据须要添加本身的agent，colletor或者storage。

　　3. Flume架构

　　　　Flume采用了分层架构，由三层组成：agent，collector和storage。其中，agent和collector均由两部分组成：source和sink，source是数据来源，sink是数据去向。

　　　　Flume的核心是Agent进程，是一个运行在服务器节点的Java进程。

 

agent：将数据源的数据发送到collector

collector：将多个agent的数据汇总后，加载到storage。它的source和sink与agent相似

storage：存储系统，能够是一个普通file，也能够是HDFS，Hive，HBase等。

 

source（数据源）：用于收集各类数据

channel：临时存放数据，能够存放在memory、jdbc、file等

sink：把数据发送到目的地，如HDFS、HBase等

Flume传输数据的基本单位是event，事务保证是在event级别进行的，event将传输的数据进行封装

只有在sink将channel中的数据成功发送出去以后，channel才会将临时数据进行删除，这种机制保证了数据传输的可靠性与安全性。

 

4. Flume的广义用法

Flume支持多级Flume的Agent，即sink能够将数据写到下一个Agent的source中，

且Flume支持扇入（source能够接受多个输入）、扇出（sink能够将数据输出多个目的地）

 

一个复杂的例子以下：有6个agent，3个collector，全部collector均将数据导入HDFS中。agent A，B将数据发送给collector A，agent C，D将数据发送给collectorB，agent C，D将数据发送给collectorB。同时，为每一个agent添加end-to-end可靠性保障，若是collector A出现故障时，agent A和agent B会将数据分别发给collector B和collector C。

 

 

 

Kafka

1. Kafka是2010年12月份开源的项目，采用scala语言编写，采用push/pull架构，更适合异构集群数据的传递方式
2. Kafka 特征

持久性消息：不会丢失任何信息，提供稳定的TB级消息存储

高吞吐量：Kafka设计工做在商用硬件上，提供每秒百万的消息

分布式架构，可以对消息分区

实时：消息由生产者线程生产出来马上被消费者看到，数据在磁盘上的存取代价为O(1)

　　3. Kafka架构

Kafka其实是一个消息发布订阅系统。Kafka将消息以Topic为单位进行概括，将向Topic发布消息的程序做为producer，预约消息的做为consumer。Kafka以集群方式运行，能够由一个或多个服务组成，每一个服务叫作一个broker。一旦有新的关于某topic的消息，broker会传递给订阅它的全部consumer。 在kafka中，消息是按topic组织的，而每一个topic又会分为多个partition，这样便于管理数据和进行负载均衡。同时，它也使用了 zookeeper进行负载均衡。

1)   Producer

向broker发送数据。

Kafka提供了两种producer接口：

a)   low_level接口，用于向特定的broker的某个topic下的某个partition发送数据；

b)   high level接口，支持同步/异步发送数据，基于zookeeper的broker自动识别和负载均衡（基于Partitioner）。producer能够经过zookeeper获取可用的broker列表，也能够在zookeeper中注册listener，该listener在添加删除broker，注册新的topic或broker注册已存在的topic时被唤醒：当producer得知以上时间时，可根据须要采起必定的行动。

2)   Broker

Broker采起了多种策略提升数据处理效率，包括sendfile和zero copy等技术。

3)   Consumer

将日志信息加载到中央存储系统上。

kafka提供了两种consumer接口：

a)   low level接口：维护到某一个broker的链接，而且这个链接是无状态的，每次从broker上pull数据时，都要告诉broker数据的偏移量。

b)   high level接口：隐藏了broker的细节，容许consumer从broker上push数据而没必要关心网络拓扑结构。更重要的是，对于大部分日志系统而言，consumer已经获取的数据信息都由broker保存，而在kafka中，由consumer本身维护所取数据信息

 

　　4. Kafka消息发送流程

1)  Producer根据指定的partition方法，将消息发布到指定topic的partition里面

2)  集群接收到Producer发送的消息后，将其持久化到硬盘，并保留消息指定时长，而不关注消息是否被消费。

3)  Consumer从kafka集群pull数据，并控制获取消息的offset

详细过程：

Kafka是一个分布式的高吞吐量的消息系统，同时兼有点对点和发布订阅两种消息消费模式。

Kafka主要由Producer，Consumer和Broker组成。Kafka中引入了一个叫“topic”的概念，用来管理不一样种类的消息，不一样类别的消息会记录在到其对应的topic池中。而这些进入到topic中的消息会被Kafka写入磁盘的log文件中进行持久化处理。对于每个topic里的消息log文件，Kafka都会对其进行分片处理。而每个消息都会顺序写入中log分片中，而且被标上“offset”的标量来表明这条消息在这个分片中的顺序，而且这些写入的消息不管是内容仍是顺序都是不可变的。因此Kafka和其它消息队列系统的一个区别就是它能作到分片中的消息是能顺序被消费的，可是要作到全局有序仍是有局限性的，除非整个topic只有一个log分片。而且不管消息是否有被消费，这条消息会一直保存在log文件中，当留存时间足够长到配置文件中指定的retention的时间后，这条消息才会被删除以释放空间。对于每个Kafka的Consumer，它们惟一要存的Kafka相关的元数据就是这个“offset”值，记录着Consumer在分片上消费到了哪个位置。一般Kafka是使用Zookeeper来为每个Consumer保存它们的offset信息，因此在启动Kafka以前须要有一个Zookeeper集群;并且Kafka默认采用的是先记录offset再读取数据的策略，这种策略会存在少许数据丢失的可能。不过用户能够灵活设置Consumer的“offset”的位置，在加上消息记录在log文件中，因此是能够重复消费消息的。log的分片和它们的备份会分散保存在集群的服务器上，对于每个partition，在集群上都会有一台这个partition存在的服务器做为leader，而这个partitionpartition的其它备份所在的服务器作为follower，leader负责处理关于这个partition的全部请求，而follower负责这个partition的其它备份的同步工做，当leader服务器宕机时，其中一个follower服务器就会被选举为新的leader。

 

 

 

数据的传递方式

1)   Socket：最简单的交互方式，典型的c/s交互模式。传输协议能够是TCP/UDP

优势：易于编程，Java有不少框架，隐藏了细节；容易控制权限，经过https，使得安全性提升；通用性强

缺点：服务器和客户端必须同时在线；当传输数据量比较大的时候，严重占用网络带宽，致使链接超时

2)   FTP/文件共享服务器方式：适用于大数据量的交互

优势：数据量大时，不会超时，不占用网络带宽；方案简单，避免网络传输、网络协议相关概念

缺点：不适合作实时类的业务；必须有共同的服务器，可能存在文件泄密；必须约定文件数据的格式

3)   数据库共享数据方式：系统A、B经过链接同一个数据库服务器的同一张表进行数据交换

优势：使用同一个数据库，使得交互更简单，交互方式灵活，可更新，回滚，由于数据库的事务，交互更可靠

缺点：当链接B的系统愈来愈多，会致使每一个系统分配到的链接不会不少；

      通常来讲，两个公司的系统不会开放本身的数据库给对方，影响安全性

4)   消息方式：Java消息服务（Java Message Service）是message数据传输的典型的实现方式

优势：JMS定义了规范，有不少消息中间件可选；消息方式比较灵活，可采起同步、异步、可靠性的消息处理

缺点：JMS相关的学习对开发有必定的学习成本；在大数据量的状况下，可能形成消息积压、延迟、丢失甚至中间件崩溃

 

1.消息队列

任何软件工程遇到的问题均可以经过增长一个中间层来解决

消息队列是在消息的传输过程当中保存消息的容器。主要目的是提供路由并保证消息的传递，若是发送消息时接收者不可用，消息队列会保留消息，直到能够成功地传递它。

2. 消息中间件做用

系统解耦：服务B出现问题不会影响服务A

削峰填谷：对请求压力实现削峰填谷，下降系统峰值压力

数据交换：无需暴露企业A和B的内网就能够实现数据交换

异步通知：减小前端和后端服务之间大量没必要要的轮询请求

　　定时任务：如生成付款检查任务，延迟30分钟