Kafka(一):初识Kafka

版权声明:本文为博主原创文章,转载请注明出处http://blog.csdn.net/saytime https://blog.csdn.net/saytime/article/details/79950563

一、消息队列相关概念

JMS ==> JAVA API

JMS即Java消息服务(Java Message Service)应用程序接口,是一个Java平台中关于面向消息中间件(MOM)的API,用于在两个应用程序之间,或分布式系统中发送消息,进行异步通信。Java消息服务是一个与具体平台无关的API,绝大多数MOM提供商都对JMS提供支持。

从使用角度看,JMS和JDBC担任差不多的角色,用户都是根据相应的接口可以和实现了JMS的服务进行通信,进行相关的操作。常见的实现JMS协议的MQ有ActiveMQ。

JMS提供了两种消息模型,peer-2-peer(点对点)以及publish-subscribe(发布订阅)模型。当采用点对点模型时,消息将发送到一个队列,该队列的消息只能被一个消费者消费。而采用发布订阅模型时,消息可以被多个消费者消费。在发布订阅模型中,生产者和消费者完全独立,不需要感知对方的存在。

消息如何从producer端达到consumer端由message-routing来决定。在JMS中,消息路由非常简单,由producer和consumer链接到同一个queue(p2p)或者topic(pub/sub)来实现消息的路由。JMSconsumer同时支持message selector(消息选择器),通过消息选择器,consumer可以只消费那些通过了selector筛选的消息。在JMS模型中,消息路由机制的图示如下:

这里写图片描述

AMQP协议

即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息,并不受客户端/中间件不同产品,不同的开发语言等条件的限制。Erlang中的实现有 RabbitMQ等。

从这一点看,AQMP可以用http来进行类比,不关心实现的语言,只要大家都按照相应的数据格式去发送报文请求,不同语言的client均可以和不同语言的server链接。

在AMQP中,消息路由(messagerouting)和JMS存在一些差别,在AMQP中增加了Exchange和binding的角色。producer将消息发送给Exchange,binding决定Exchange的消息应该发送到那个queue,而consumer直接从queue中消费消息。queue和exchange的bind有consumer来决定。AMQP的routing scheme图示过程如下:

这里写图片描述

对比项 JMS AMQP
定义 Java api Wire-protocol
跨语言
跨平台
Model 提供两种消息模型:(1)、Peer-2-Peer(2)、Pub/sub Pub/sub提供了五种消息模型:(1)、direct exchange(2)、fanout exchange(3)、topic change(4)、headers exchange(5)、system exchange
支持消息类型 多种消息类型:TextMessage、MapMessage、BytesMessage、StreamMessage、ObjectMessage byte[]当实际应用时,有复杂的消息,可以将消息序列化后发送。

二、常见MQ对比

这里写图片描述

Kafka对比ActiveMQ, RabbitMQ最大的区别:
- Kafka支持动态扩容
- ActiveMQ、RabbitMQ在消费者消费消息之后,消息会删除,而Kafka消费者消费后,消息还会继续保存两天时间。

三、什么是kafka

http://kafka.apache.org/intro

官方介绍:
Apache Kafka® is a distributed streaming platform
Kafka 是一个分布式数据流处理系统

1.1 主要的三种功能:

1. Publish and subscribe to streams of records, similar to a message queue or enterprise messaging system.
    发布订阅记录流, 类似于消息队列或者企业消息系统

2. Store streams of records in a fault-tolerant durable way.
    系统具备在存储数据时具备容错能力

3. Process streams of records as they occur.
    系统具备在数据流触发时进行实时处理

1.2 使用场景

1. Building real-time streaming data pipelines that reliably get data between systems or applications
    在系统或应用间需要相互进行数据流交互处理的实时系统

2. Building real-time streaming applications that transform or react to the streams of data
    需要对数据流中的数据进行转换或及时处理的实时系统

1.3 Kafka速度快的原因
- 采用零拷贝技术,让数据传输更快
- 采用批量的数据读取,减少磁盘的IO操作
- 为了保证历史消息可以继续被读取,提供了offset指向,通过指向进行消息的顺序读取
- 网络的传输采用数据压缩格式,所以传输更快,占用的带宽更少
- Kafka的数据可以设置副本,这样在出现问题之后可以保证数据继续可用。

四、Kafka 基本知识

Broker:消息中间件处理结点,一个Kafka节点就是一个broker,多个broker可以组成一个Kafka集群。
Topic:一类消息,Kafka集群能够同时负责多个topic的分发。
Partition:topic物理上的分区,一个topic可以分为多个partition,每个partition是一个有序的队列。
Segment:partition物理上由多个segment组成。
offset:每个partition都由一系列有序的、不可变的消息组成,这些消息被连续的追加到partition中。partition中的每个消息都有一个连续的序列号叫做offset,用于partition唯一标识一条消息。由于Kafka的消息消费之后还继续保存两天,所以设计了一个下标偏移量,其他如RabbitMQ消息消费完自动删除,所以不需要这个。
Producer:负责发布消息到Kafka broker。
Consumer:消息消费者,向Kafka broker读取消息的客户端。
Consumer Group:每个Consumer属于一个特定的Consumer Group。

这个图表示一个Kafka集群,有两台kafka服务器,server1和server2中都有一个相同的Topic, 而在server1中Topic有两个分区,server2中Topic有三个分区。
这里写图片描述

一个Topic分区的描述, 记录追加到每个分区的后面。

这里写图片描述

下标表示偏移量offset,每个消费者读取的偏移量可以不一样。如消费者A读取的下标是9,消费者读取的下标是11

这里写图片描述

Producer发送消息时可以指定发送到哪个分区,也可以采用指定均衡策略,由指定均衡存储到某个分区,不配置时,默认采用随机均衡策略存储。

如下图:两个服务器的kafka集群管理四个分区(P0-P3)作用于两个消费者组。消费组A有两个消费者实例,消费组B有四个消费者实例。

这里写图片描述

在kafka的设计中,可以有多个不同的group来同时消费同一个topic下的消息,如图,我们有两个不同的group同时消费,他们的的消费的记录位置offset各不项目,不互相干扰。对于一个group而言,消费者的数量不应该多余分区的数量,因为在一个group中,每个分区至多只能绑定到一个消费者上,即一个消费者可以消费多个分区,一个分区只能给一个消费者消费,因此,若一个group中的消费者数量大于分区数量的话,多余的消费者将不会收到任何消息。

Kafka的消息保存在Topic中,Topic中有多个分区,为保证数据的安全性,每个分区又有多个Replica,分区中消息存储由多个Segment组成。

如图,一个Topic有N个分区,然后每个分区有N个副本,多个副本之间会选举出一个leader,当有生产者push消息到Leader时,其他Follower会从leader pull 消息实现同步。

注意,生产者和消费者都只与Leader进行数据交互,Follower只与Leader进行数据传输,当Leader挂掉,Follower之间会重新选举出一个Leader.

这里写图片描述

阅读更多

没有更多推荐了,返回首页