文档章节

彻头彻尾的了解Kafka存在的背景与意义

牧师-Panda
 牧师-Panda
发布于 2017/08/27 15:48
字数 1449
阅读 47
收藏 1

Kafka是什么

简单的说,Kafka是由Linkedin开发的一个分布式的消息队列系统(Message Queue)

如果你对什么是消息队列系统,以及消息队列系统的功能一无所知,可以认真研读一下这篇博文

于是下面我们谈论的话题,是建立在你了解消息队列以及一些大型网站的知识的基础之上的。

Kafka想干什么

kafka开发的主要初衷目标是构建一个用来处理海量日志用户行为网站运营统计等的数据处理框架。在结合了数据挖掘行为分析运营监控等需求的情况下,需要能够满足各种实时在线批量离线处理应用场合对低延迟批量吞吐性能的要求。从需求的根本上来说,高吞吐率是第一要求,其次是实时性和持久性。

既有的消息队列框架或者对消息传送的可靠性提供了较高的保证,由此带来较大的负担,不能满足海量高吞吐率的要求;或者完全面向实时消息处理系统,对于批量离线处理的场合无法提供足够的缓存和持久性要求。

而多数针对大数据开发应用的日志收集处理系统(e.g. scribe, flume)则通常更适合批量离线处理场合,对实时在线处理的场合支持不够。

总而言之,Kafka试图提供一个同时满足在线和离线处理海量数据的消息派发系统。

Kafka如何实现

kafka的集群有多个Broker服务器组成,每个类型的消息被定义为topic,同一topic内部的消息按照一定的key和算法被分区(partition)存储在不同的Broker上,消息生产者producer和消费者consumer可以在多个Broker上生产/消费topic,如图所示:

以高效率作为第一设计原则,kafka的结构设计在很多方面都做了激进的取舍。

消息队列是以log文件的形式存储,消息生产者只能将消息添加到既有的文件尾部没有任何ID信息用于消息的定位,完全依靠文件内的位移,因此消息的使用者只能依靠文件位移顺序读取消息,这样也就不需要维护复杂的支持随即读取的索引结构

kafka broker完全不维护和协调多用户使用消息的行为模式,用户自己维护位移用来索引消息。

最小的并发访问单位就是partition分区,同一用户组内的所有用户(可以理解为同一个应用的所有并发进程)只能有一个访问同一分区,同时分区的个数是固定的,不支持动态调整。这样最大简化了多进程/分布式client之间对消息处理访问的并发控制的复杂度,当然也带来一定的使用模式上的限制(比如最大并发度完全取决于预先规划的partition的个数)

此外分区也带来一个问题就是消息只是分区内部有序而不是全局有序的。如果需要全局有序,应用需要自己靠别的机制来保证。

使用Pull模式派发消息,消息的使用情况,比如是否还有consumer没有读取,是否重复读取(改进中)等,在Broker端也完全不跟踪维护,消息的过期处理简单的由定时器定时删除(比如保留7天),由此简化各种消息跟踪维护的开销。

采取各种方式最大化数据传输效率

比如生产者和消费者可以批量读写消息减少RPC开销

使用Zero Copy方式在内核层直接将文件内容传送给网络Socket,避免应用层数据拷贝

使用合理的压缩格式等

激进的内存管理模式

基本的意思就是不管理。。。kafka不在JVM进程内部维护消息Cache,消息直接从文件中读写,完全依赖操作系统在文件系统层面的cache,避免在JVM中管理Cache带来的额外数据结构开销和GC带来的性能代价。基于批量处理和顺序读写的应用模式,最大化利用文件系统的Cache机制和规避文件读写相对内存读写的性能代价。

高可用性

kafka在0.8之前message是没有备份容错机制的,producer的工作模式是fire and forget,如果一个broker失效,那么相关topic分区的相关消息也就丢失了。这种设计的原因在于最初的应用模式,如日志/用户行为等消息的处理,对数据的健壮性方面要求不高,可以容忍部分数据的缺失。采用fire and forget 模式,不需要等待Broker ack,有利于提高producer的吞吐率。

不过在0.8版本中,添加了数据replica的机制,一个消息分区的多个replica分布在不同的Broker上,由leader replica负责日常读写,通过zookeeper监督failover,不同的分区的leader replica均衡负载到不同的Broker上。在这种情况下,producer可以选择不等待leader replica的Ack,部分Ack,或者完全备份完毕后Ack等不同的ack机制。这三种机制,性能依次递减 (producer吞吐量降低1-3倍),数据健壮性则依次递增。

 

 

 

 

 

© 著作权归作者所有

共有 人打赏支持
牧师-Panda
粉丝 32
博文 146
码字总数 180044
作品 0
浦东
私信 提问
Storm-kafka【接口实现】4-1:ZKCoordinator: ZK协调器

阅读背景:您需要对Zk,Kafka有基础的了解 本章主题:详尽的梳理ZkCoordinator的过程 package com.mixbox.storm.kafka; import org.slf4j.Logger;import org.slf4j.LoggerFactory; import com......

止静
2014/07/23
0
0
交易系统使用storm,在消息高可靠情况下,如何避免消息重复

概要:在使用storm分布式计算框架进行数据处理时,如何保证进入storm的消息的一定会被处理,且不会被重复处理。这个时候仅仅开启storm的ack机制并不能解决上述问题。那么该如何设计出一个好的...

刘洋intsmaze
2016/12/26
0
0
Kafka 源码分析1 : 基础搭建和项目结构介绍

原文出处:刘正阳 背景 从kafka也算有两年了,用它做了不少项目,但是之前对它的认识也仅仅停留在一些从其他地方听到的概念和官方文档的documentation上在遇到一些问题时往往不知道其原理只能...

刘正阳
05/16
0
0
spring-kafka中argumentResolvers.add(new MessageMethodArgumentResolver())缺失MessageConverter参数

今天给项目升级Kafka版本,从1.0.0升级到1.0.5,修改了相关的配置后,启动项目,抛出异常如下: 下载源码后, 进入内部类,发现 方法中的, 缺失了参数,作为成熟的消息中间件,不应该存在这...

Neon_Wang
2017/07/05
422
1
Spark 从 Kafka 读数并发问题

经常使用 Apache Spark 从 Kafka 读数的同学肯定会遇到这样的问题:某些 Spark 分区已经处理完数据了,另一部分分区还在处理数据,从而导致这个批次的作业总消耗时间变长;甚至导致 Spark 作...

Kafka
09/09
0
0

没有更多内容

加载失败,请刷新页面

加载更多

Spring源码学习笔记-1-Resource

打算补下基础,学习下Spring源码,参考书籍是《Spring源码深度解析》,使用版本是Spring 3.2.x,本来想试图用脑图记录的,发现代码部分不好贴,还是作罢,这里只大略记录下想法,不写太细了 ...

zypy333
今天
10
0
RestClientUtil和ConfigRestClientUtil区别说明

RestClientUtil directly executes the DSL defined in the code. ConfigRestClientUtil gets the DSL defined in the configuration file by the DSL name and executes it. RestClientUtil......

bboss
今天
16
0

中国龙-扬科
昨天
2
0
Linux系统设置全局的默认网络代理

更改全局配置文件/etc/profile all_proxy="all_proxy=socks://rahowviahva.ml:80/"ftp_proxy="ftp_proxy=http://rahowviahva.ml:80/"http_proxy="http_proxy=http://rahowviahva.ml:80/"......

临江仙卜算子
昨天
10
0
java框架学习日志-6(bean作用域和自动装配)

本章补充bean的作用域和自动装配 bean作用域 之前提到可以用scope来设置单例模式 <bean id="type" class="cn.dota2.tpye.Type" scope="singleton"></bean> 除此之外还有几种用法 singleton:......

白话
昨天
10
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部