文档章节

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

牧师-Panda
 牧师-Panda
发布于 2017/08/27 15:48
字数 1449
阅读 97
收藏 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
粉丝 33
博文 146
码字总数 180044
作品 0
浦东
私信 提问
加载中

评论(0)

Kafka 基本概念以及框架介绍

背景及架构介绍 一、 背景 什么是kafka呢,他是LinkedIn开发的一个分布式消息系统,用scala编写的,可以水平扩展和高吞吐率。 原本开发自LinkedIn,用作他们的活动流和运营数据处理管道的基础...

osc_vy694i16
2019/02/22
4
0
交易系统使用storm,在消息高可靠情况下,如何避免消息重复

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

刘洋intsmaze
2016/12/26
0
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
936
0
kafka消费者处理能力低引起rebalance分析

一.背景介绍 项目上进行算法调度的需求,打算采用kafka作为消息中间件,通过将多个算法消费者加入到同一个group中并行的处理算法请求,从而达到高效处理的目的。但是算法处理的时间较长,多则...

osc_lrhgywny
2019/12/27
4
0
Kafka 源码分析1 : 基础搭建和项目结构介绍

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

刘正阳
2018/05/16
0
0

没有更多内容

加载失败,请刷新页面

加载更多

直接显示StackOverflow的答题日期, 增加评论区回复的时间显示 ,修改时间显示到小时分。

// ==UserScript==// @name 直接显示StackOverflow的答题日期, 增加评论区回复的时间显示 ,修改时间显示到小时分。// @namespace http://tampermonkey.net/// @version ...

FalconChen
今天
36
0
Shader笔记_005 纹理

纹理最初的目的就是使用一张图片来控制模型的外观,通过纹理映射技术 我们可以把一张图粘贴在物体表面,逐纹素的控制模型的颜色。 通常美术建模的时候也会在软件里利用纹理展开技术把纹理展开成...

STONE-CITY
今天
12
0
iOS MVVM 与RAC结合使用

MVVM配合 RAC 更能发挥的淋漓尽致。 我们把 MVVM 第一篇的例子 KVO 的事件 替换成 配合RAC 框架使用, OC的话直接导入 : pod 'ReactiveObjC' Swift 直接用 RXSwift就可以。 把 ViewModel里加...

T型人才追梦者
今天
22
1
OSChina 周一乱弹 —— 影响心情的三座大山

Osc乱弹歌单(2020)请戳(这里) 【今日歌曲】 @薛定谔的兄弟 :分享洛神有语创建的歌单「我喜欢的音乐」: 《浮生(inst.)》- 忘乡 / 墨凡悦 手机党少年们想听歌,请使劲儿戳(这里) @凝小紫...

小小编辑
今天
55
0
Unity中头发渲染

头发与普通PBR 材质最大的区别是 头发是各项异性的高光, 参考实现主要为下面文章 http://web.engr.oregonstate.edu/~mjb/cs519/Projects/Papers/HairRendering.pdf 头发包含 2个高光,以及高...

liyong2
今天
20
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部