kafka入门介绍

背景:

当今社会各种应用系统诸如商业、社交、搜索、浏览等像信息工厂一样不断的生产出各种信息,在大数据时代,我们面临如下几个挑战:

  1. 如何收集这些巨大的信息
  2. 如何分析它
  3. 如何及时做到如上两点

以上几个挑战形成了一个业务需求模型,即生产者生产(produce)各种信息,消费者消费(consume)(处理分析)这些信息,而在生产者与消费者之间,需要一个沟通两者的桥梁-消息系统。

从一个微观层面来说,这种需求也可理解为不同的系统之间如何传递消息。

Kafka诞生:由 linked-in 开源

kafka-即是解决这类问题的一个框架,它实现了生产者和消费者之间的无缝连接。

kafka-高产出的分布式消息系统(A high-throughput distributed messaging system)

Kafka特性:它形容自己的设计是独一无二的,先看一下它有如何过人之处:

  • 快:单个kafka服务每秒可处理数以千计客户端发来的几百MB数据。
  • 可扩展性:一个单一集群可作为一个大数据处理中枢,集中处理各种类型业务
  • 持久化:消息被持久化到磁盘(可处理TB数据级别数据但仍保持极高数据处理效率),并且有备份容错机制
  • 分布式:着眼于大数据领域,支持分布式,集群可处理每秒百万级别消息
  • 实时性:生产出的消息可立即被消费者消费

Kafka的组件:

  • topic:消息存放的目录即主题
  • Producer:生产消息到topic的一方
  • Consumer:订阅topic消费消息的一方
  • Broker:Kafka的服务实例就是一个broker

如下图所示,Producer生产的消息通过网络发送给Kafka cluster,而Consumer从其中消费消息

Topic 和Partition:

消息发送时都被发送到一个topic,其本质就是一个目录,而topic由是由一些Partition Logs(分区日志)组成,其组织结构如下图所示:

(一个主题可以包含多个分区)

我们可以看到,每个Partition中的消息都是有序的,生产的消息被不断追加到Partition log上,其中的每一个消息都被赋予了一个唯一的offset值。

Kafka集群会保存所有的消息,不管消息有没有被消费;我们可以设定消息的过期时间,只有过期的数据才会被自动清除以释放磁盘空间。比如我们设置消息过期时间为2天,那么这2天内的所有消息都会被保存到集群中,数据只有超过了两天才会被清除。

Kafka需要维持的元数据只有一个--消费消息在Partition中的offset值,Consumer每消费一个消息,offset就会加1。其实消息的状态完全是由Consumer控制的,Consumer可以跟踪和重设这个offset值,这样的话Consumer就可以读取任意位置的消息。

把消息日志以Partition的形式存放有多重考虑,第一,方便在集群中扩展,每个Partition可以通过调整以适应它所在的机器,而一个topic又可以有多个Partition组成,因此整个集群就可以适应任意大小的数据了;第二就是可以提高并发,因为可以以Partition为单位读写了。

分布式:

(主从集群)

这些Partitions分布在集群的每一台server上,而每一个Partition在集群中都可以有多个备份,这个备份数量是可配置的。

每个Partition都有一个leader server,而其他备份的server都称为followers,只有leader服务器才会处理这个Partition上所有的读写请求,而其它followers则被动的复制leader上的数据。如果一个leader挂掉了,followers中的一个服务器则会自动升级为leader。因此,其实集群中的每个服务器都扮演着一个Partition的leader服务器,和其它Partition的follower服务器。

Producers:

Producer可以根据自己的选择发布消息到一个主题,Producer也可以自己决定把消息发布到这个主题的哪个Partition,当然我们可以选择API提供的简单的分区选择算法,也可以自己去实现一个分区选择算法。

Consumers:

消息传递通常由两种模式,queuing(队列)和publish-subscribe (发布-订阅)

  • queuing:每个Consumer从消息队列中取走一个消息
  • pub-scrib:消息被广播到每个Consumer

Kafka通过提供了一个对Consumer的抽象来同时实现这两种模式-ConsumerGroup。Consumer实例需要给自己指定一个ConsumerGroup的名字,如果所有的实例都用同一个ConsumerGroup名字,那么这些Consumer就会以queuing的模式工作;如果所有的实例分别用的不同的ConsumerGroup名字,那么它们就以public-subscribe模式工作。

(group的概念只针对于客户端,如果有多个客户端定义了多个组时,broker会以pub-scrib的形式将消息发送到每一个group上)

如下图所示:含两台server的集群一共有p0~p3四个Partition,两个Consumer Group,在Group内部是以queuing的模式消费Partition,在Group之间是以pub-scrib模式消费。

消息顺序性:

Kafka是如何确保消息消费的顺序性的呢?前面讲到过Partition,消息在一个Partition中的顺序是有序的,但是Kafka只保证消息在一个Partition中有序,如果要想使整个topic中的消息有序,那么一个topic仅设置一个Partition即可。

原文发布于微信公众号 - Spark学习技巧(bigdatatip)

原文发表时间:2018-05-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java后端技术栈

Kafka设计解析(一)- Kafka背景及架构介绍

http://www.jasongj.com/2015/03/10/KafkaColumn1

19110
来自专栏静晴轩

Npm vs Yarn 之备忘详单

有则笑话,如此讲到:“老丈人爱吃核桃,昨天买了二斤陪妻子送去,老丈人年轻时练过武,用手一拍核桃就碎了,笑着对我说:你还用锤子,你看我用手就成。我嘴一抽,来了句:...

35830
来自专栏hadoop学习笔记

深度解析(一):大快DKM企业大数据管理平台基本功能

之前几周的时间一直是在围绕DKhadoop的运行环境搭建写分享,有一些朋友留言索要了dkhadoop安装包,不知道有没有去下载安装一探究竟。关于DKHadoop...

21450
来自专栏Spark学习技巧

Apache Spark:来自Facebook的60 TB +生产用例

浪尖整理翻译https://databricks.com/blog/2016/08/31/apache-spark-scale-a-60-tb-producti...

18120
来自专栏包子铺里聊IT

5分钟深入浅出 HDFS

通过前面几篇文章的介绍,我们深入讨论了 Hadoop MapReduce 处理数据的过程,以及优化 MapReduce 性能的方方面面。 期间被反复提及的 HD...

32360
来自专栏IT技术精选文摘

Kafka剖析系列之背景及架构介绍

Kafka是由LinkedIn开发的一个分布式的消息系统,使用Scala编写,它以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布式处理系统如Cloud...

24050
来自专栏大数据

浅析大数据HIVE和HBASE有何区别

Apache Hive是一个构建在Hadoop基础设施之上的数据仓库。通过Hive可以使用HQL语言查询存放在HDFS上的数据。HQL是一种类SQL语言,这种语...

28160
来自专栏美图数据技术团队

大数据集群安全组件解析(含代码)

感谢阅读「美图数据技术团队」的第 5 篇文章,关注我们持续获取美图最新数据技术动态。

19120
来自专栏即时通讯技术

一套高可用、易伸缩、高并发的IM群聊架构方案设计实践

本文原题为“一套高可用群聊消息系统实现”,由作者“于雨氏”授权整理和发布,内容有些许改动,作者博客地址:alexstocks.github.io。应作者要求,...

30220
来自专栏祝威廉

如何基于Yarn开发你的分布式程序

这篇文章不会具体教你如何使用Yarn的API,但是会教你我实践过后的一些经验。接下来的内容会探讨以下两个主题:

10140

扫码关注云+社区

领取腾讯云代金券