kafka对于构建实时的数据管道和流应用是很有用的。
Apache Kafka是一个分布式的流平台。这是什么意思呢?
我们考虑流平台有三个关键的能力:
Kafa有什么用呢?
它被用于两类应用:
那么Kafka是怎样做到这些事情的呢?
首先来看一些概念:
Kafka有四个核心的API:
在Kafka中,客户端和服务器端的通信被做成是简单的、高性能的、基于TCP协议的。
让我们首先深入到核心抽象,Kafka提供a stream of records —— the topic
一个topic是一个分类,记录是被发布到这里面的。在Kafka中,topics总是有多个订阅者的;因此,一个topic可以有多个0个,1个,或者多个消费者来订阅的。
每个topic,Kafka集群维护一个partitioned log(分区日志),它们看起来是这个样子的:
每个分区都是一个有序的、不可变的序列,这些序列都是结构化的提交日志。分区中的每个记录都被指定了一个序列id编号,被称之为offset,而且它是分区中每条记录的唯一标识。
Kafka集群操持所有的发布记录,无论这些记录是否已经被消费,这一点是可以配置的。例如,如果这个保留策略设置的是2天,那么一个记录被发布过了2天以后它仍然可以被消费,但是为了腾出空间来,它可能会被丢弃。Kaka的性能是高效的稳定的,所有存储数据很长时间不是一个问题。
事实上,元数据是保存在每个消费者那里的,最基本的是offset或者叫position,它们都是以消费者日志形式保存的。offset是由消费者来控制的:通常一个消费者会增长它的偏移量,事实上,自从消费者可以控制位置它可以以任意顺序消费记录。例如,一个消费者可以重置到一个旧的offset以处理之前的记录。
这个特性就意味着,kafka的消费者是非常廉价的 —— 它们可以来去自如而不受集群和其它消费者的影响。
日志分区有几个目的。第一,允许日志是伸缩的,大小可以超过单个服务器,每一个独立的分区必须安装在它所在主机的那个服务器上,但是一个topic可以有多个分区,所有它可以处理任意数量的数据。第二,作为一个并行单元。
日志分区是被分布在集群中的服务器上的,每个服务器处理数据和请求都共享这些分区。为了容错,每个分区会交叉复制,副本的数据是可以配置的。
每个分区中有一个服务器充当“leader”,有0个或者多个服务器充当“followers”。leader处理所有的读和写请求,而follower被动的从leader那里复制。如果leader失败了,其中一个follower将自动成为新的leader。每个充当leader的服务器可能是一些分区的leader,同时又是另一些分区的follower,所以在集群中负载是平衡的。
生成者发布数据到topics。生产者负责选择哪个记录指定到哪个分区。可以以一个轮询的方式简单的来实现负载均衡。
消费者用一个“consumer group name”来标记它们自己,topic中的每个记录被投递到一个订阅者消费组中的一个消费者实例。每个消费者实例分开处理。
如果所有的消费者实例都在相同的消费者组中,那么记录有效的在消费者之间负载均衡。
如果所有的消费者实例在不同的消费者组中,那么每一条记录都会被广播给所有的消费者。
如图,一个Kafka集群有2个服务器,4个分区(P0—P3),2个消费者分组。消费者分组A有2个消费者实例,组B有4个。
通常,我们会发现,topic有许多消费者分组,每个组都是一个"logical subscriber"(逻辑订阅者)。每个组由许多消费者实例组成,实例是可伸缩的可容错的。
Kafka只提供分区中的记录的总的顺序,而不保证分区之间的顺序。
一个高级别的kafka给出下列保证:
消息传统上有两种模型:queuing 和 publish-subscribe(点对点队列模型和发布订阅模型)。在队列模型中,每个消息只能被消费一次;在发布订阅模型中,消息可以广播给所有的消费者。这两种模型各有利弊。
Kafka中的消费者分组的概念就是在从这两种模型中衍生出来的。和队列模型一些,消费者分组允许你在处理集合之上分开处理。和发布订阅模型一样,kafka允许你广播消息给多个消费者分组。
Kafka的模型的优势在于它的每个topic有这样一些属性:它可以伸缩处理,而且它有多个订阅者
相对于传统的消息系统而言,Kakfa有更强的顺序保证。
传统的队列在服务器上按顺序保存记录,而且多个消费者从队列中消费记录是按照记录被存储的顺序来消费的。虽然服务器是按顺序处理记录的,但是记录是异步投递给消费者的,所以它们可能以不同的顺序到达消费者。也就是说,在并行消费的时候会丢失一定百分比的顺序。消息系统中一个概念叫"exclusive consumer"它允许只能有一个消费者来处理,也就意味着是串行处理。
Kafka做得更好。它有一个概念叫“parallelism—the partition—within the topics”(在topics的分区下的并行)。kafka既保证顺序同时还提供负载均衡。这一切都归功于给消费者分组中的消费者指定topic的分区,以至于每个分区都可以被一个消费者精确的消费。注意分组中的消费者数量不能比分区数还多。
任何消息队列都允许发布消息和消费消息解耦,在这个过程中扮演一个存储系统的角色。写到kafka的数据被写到磁盘并且被复制。kafka允许生产者等待确认,以至于只有当数据被完全复制并且保证已经被持久化了才能认为这个写操作是完成的。
不管你是持久化50KB还是50TB的数据,kakfa执行的操作都是一样的。
你可以把kafka当做一种特别的分布式文件系统,它高性能、低延迟的提交日志存储、副本。
仅仅只是读写存储流数据是不够的,要能够实时处理流。
kafka的流处理器是从输入topic那里持续不断的接收流,然后对这些输入做一些处理,并且生成持续不断的流数据到输出topic。
例如,一个零售应用可能采集销售和物流的的数据作为输入流,然后基于这些数据进行计算,从而生成再次订购和价格调整的输出流。
参考 http://kafka.apache.org/intro
1、kafka是一个分布式的流平台
2、kafka有什么用?
3、基本概念
4、核心API
5、主题和日志
5.1、一个主题就是一个分类,记录被发布到某个主题中,主题总是有多个订阅者,一个主题可以有0个或1个或多个消费者
5.2、每个主题都有一个分区日志。每个分区都是一个有序的、不可变的记录序列,记录被持续不断的追加到分区中
5.3、记录是一个结构化的提交日志(a structured commit log)
5.4、分区中的每条记录都被指定了一个唯一的id号,叫做offset。offset是由消费者控制的。
5.5、kafka保存所有已发布的记录,不管它们是不是已经被消费。保留的周期是可配置的。
5.6、为什么要分区呢?分区可以突破单台服务器的限制。
6、分布
6.1、日志分区被分布在集群中的服务器之上,这些分区之下的每个服务器处理数据和请求的时候共享此分区,每个分区会被复制到其它服务器上,副本的数量可配置。
6.2、每个分区中,有一个服务器充当"leader"的角色,有0个或者多个充当"follower"的角色。leader负责处理所有读写请求,而follower被动的从leader那里复制。如果leader死了,其中一个follower会自动成为leader。一个服务器可能是它所在的那些分区的其中一个分区的leader的同时也可能是其它分区的follower。(PS:这段话的意思是,一个分区可能有1台或者多台服务器组成,在组成个分区的服务器中有一个服务器是leader角色,其余是follower角色,leader角色负责这个分区的所有读写操作,而follower则被动的从leader那里复制数据。而且,一个服务器可能在这个分区的leader,但同时也可能是别的分区的follower。)
7、生产者
生产者负责指定记录发布到哪个topic的哪个分区中
8、消费者
8.1、消费者用消费者组名来标记它们自己,每个消费者分组都是topics的一个逻辑订阅者
8.2、被发布到topics中的每一条记录会被投递到每个订阅的消费者分组中的一个消费实例
8.3、每个消费者分组由多个消费者实例组成,而且实例的数量是可伸缩的
9、保证
10、kafka作为消息系统
10.1、topics中的每条记录只会被投递到每个订阅的消费者分组中的一个消费者实例。也就是说,假设有2个消费者分组都订阅了这个topics,并且每个分组都有3个消费者实例,那么这个topics中的每条记录只会投递2份分别给这两个分组,每个分组收到这条记录以后只能由该分组中的一个消费者实例消费。
10.2、基于第一点,那么,如果订阅这个topics的所有消费者都属于同一个分组,那么这就相当于点对点队列模型;如果订阅的所有消费者都属于不同的消费者分组,那么这就相当于是发布订阅模型。
10.3、kafka保证同一个生产者发送到同一个topics下的同一个分区的消息的存储顺序和它们发送的顺序一致,而且消费这个分区的消费者看到消息的顺序和它们存储的顺序是一样的。
10.4、主题下分区中并行,kafka既保证顺序又能够负载均衡。这一切都归功于指定分区到分组中的消费者,以至于每个分区只能被消费者分组中的一个消费者消费。通过这样做,就可以确保消费者只能按顺序消费数据。
11、两张很重要的图
如对本文有疑问, 点击进行留言回复!!
unity的错误解决办法:NullReferenceException: Object reference not set to an instance of an object;tiny proje
Hadoop 之 HDFS (HDFS 数据流的 读写 流程)
听说你一读Spring源码就懵逼?我帮你把架子搭好了,你填就行!
首席架构师推荐:金融保险领域数字化转型实践--如何优雅地修改业务中台中分层应用Maven多模块的版本号?(命令导入式)
[JVM学习之路]一、初识JVM,了解其结构、模型及生命周期
网友评论