Kafka介绍

最新推荐文章于 2024-09-09 00:13:44 发布

yangtz_1999

最新推荐文章于 2024-09-09 00:13:44 发布

阅读量481

点赞数 1

分类专栏：横向扩展

本文链接：https://blog.csdn.net/Young_Fee/article/details/92838731

版权

横向扩展专栏收录该内容

6 篇文章 0 订阅

订阅专栏

Kafka

Kafka. 1

1. 消息队列（Message Queue) 1

a) Kafka的Producers. 3

c) Kafka的Broker 3

d) Kafka的Broker无状态机制... 3

e) Kafka的Message组成... 4

f) Kafka的Partitions分区的目的... 4

g) Kafka的Consumers. 4

14. kafka java操作... 10

消息队列（Message Queue)

MQ的模型

消息队列分类

点对点:
- 消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。
- 注意：
- 消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。
- Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。
发布/订阅:

消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。

消息队列MQ对比

RabbitMQ：支持的协议多，非常重量级消息队列，对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。
ZeroMQ：号称最快的消息队列系统，尤其针对大吞吐量的需求场景，擅长的高级/复杂的队列，但是技术也复杂，并且只提供非持久性的队列。
ActiveMQ：Apache下的一个子项，类似ZeroMQ，能够以代理人和点对点的技术实现队列。
Redis：是一个key-Value的NOSql数据库，但也支持MQ功能，数据量较小，性能优于RabbitMQ，数据超过10K就慢的无法忍受

Kafka简介

Kafka 是分布式发布-订阅消息系统。它最初由 LinkedIn 公司开发，使用 Scala语言编写,之后成为 Apache 项目的一部分。Kafka 是一个分布式的，可划分的，多订阅者,冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。

Kafka的特点

同时为发布和订阅提供高吞吐量。据了解，Kafka 每秒可以生产约 25 万消息（50 MB），每秒处理 55 万消息（110 MB）。
可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如 ETL，以及实时应用程序。通过将数据持久化到硬盘以及 replication 防止数据丢失。
分布式系统，易于向外扩展。所有的 producer、broker 和 consumer 都会有多个，均为分布式的。无需停机即可扩展机器。
消息被处理的状态是在 consumer 端维护，而不是由 server 端维护。当失败时能自动平衡。
支持 online 和 offline 的场景。

Kafka的逻辑架构

Kafka的核心概念

Producer 特指消息的生产者
Consumer 特指消息的消费者
Consumer Group 消费者组，可以并行消费Topic中partition的消息
Broker：缓存代理，Kafa 集群中的一台或多台服务器统称为 broker。
Topic：特指 Kafka 处理的消息源（feeds of messages）的不同分类。
Partition：Topic 物理上的分组，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。partition 中的每条消息都会被分配一个有序的 id（offset）。
Message：消息，是通信的基本单位，每个 producer 可以向一个 topic（主题）发布一些消息。
Producers：消息和数据生产者，向 Kafka 的一个 topic 发布消息的过程叫做 producers。
Consumers：消息和数据消费者，订阅 topics 并处理其发布的消息的过程叫做 consumers。

Kafka的Producers

消息和数据生产者，向 Kafka 的一个 topic 发布消息的过程叫做 producers。
Producer将消息发布到指定的Topic中,同Producer也能决定将此消息归属于哪个partition;比如基于"round-robin"方式或者通过其他的一些算法等.
异步发送

批量发送可以很有效的提高发送效率。Kafka producer的异步发送模式允许进行批量发送，先将消息缓存在内存中，然后一次请求批量发送出去。

Kafka的Broker

Broker：缓存代理，Kafka 集群中的一台或多台服务器统称为 broker。
Message在Broker中通Log追加的方式进行持久化存储。并进行分区（patitions)
为了减少磁盘写入的次数,broker会将消息暂时buffer起来,当消息的个数(或尺寸)达到一定阀值时,再flush到磁盘,这样减少了磁盘IO调用的次数。

Kafka的Broker无状态机制

1. Broker没有副本机制，一旦broker宕机，该broker的消息将都不可用。

2. Broker不保存订阅者的状态，由订阅者自己保存。

3. 无状态导致消息的删除成为难题（可能删除的消息正在被订阅），kafka采用基于时间的SLA(服务水平保证)，消息保存一定时间（通常为7天）后会被删除。

4. 消息订阅者可以rewind back到任意位置重新进行消费，当订阅者故障时，可以选择最小的offset(id)进行重新读取消费消息。

Kafka的Message组成

Message消息：是通信的基本单位，每个 producer 可以向一个 topic（主题）发布一些消息。
Kafka中的Message是以topic为基本单位组织的，不同的topic之间是相互独立的。每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定的)，每个partition存储一部分Message。
partition中的每条Message包含了以下三个属性：

offset 对应类型：long

MessageSize 对应类型：int32

data 是message的具体内容

Kafka的Partitions分区的目的

kafka基于文件存储.通过分区,可以将日志内容分散到多个server上,来避免文件尺寸达到单机磁盘的上限,每个partiton都会被当前server(kafka实例)保存;
可以将一个topic切分多任意多个partitions,来消息保存/消费的效率.
越多的partitions意味着可以容纳更多的consumer,有效提升并发消费的能力.

Kafka的Consumers

消息和数据消费者，订阅 topics 并处理其发布的消息的过程叫做 consumers。
在 kafka中,我们可以认为一个group是一个“订阅者”,一个Topic中的每个partions,只会被一个“订阅者”中的一个consumer消费,不过一个 consumer可以消费多个partitions中的消息（消费者数据小于Partions的数量时）
注： kafka的设计原理决定,对于一个topic,同一个group中不能有多于partitions个数的consumer同时消费,否则将意味着某些consumer将无法得到消息.

Kafka的持久化

数据持久化：

发现线性的访问磁盘，很多时候比随机的内存访问快得多

传统的使用内存做为磁盘的缓存

Kafka直接将数据写入到日志文件中

日志数据持久化特性：

写操作：通过将数据追加到文件中实现

读操作：读的时候从文件中读就好了

优势：读操作不会阻塞写操作和其他操作，数据大小不对性能产生影响；

没有容量限制（相对于内存来说）的硬盘空间建立消息系统；

线性访问磁盘，速度快，可以保存任意一段时间！

一个Topic可以认为是一类消息，每个topic将被分成多partition(区),每个partition在存储层面是append log文件。任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量）,partition是以文件的形式存储在文件系统中。
Logs文件根据broker中的配置要求,保留一定时间后删除来释放磁盘空间。

Partition：

Topic 物理上的分组，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。 partition 中的每条消息都会被分配一个有序的 id（offset）。

为数据文件建索引：稀疏存储，每隔一定字节的数据建立一条索引。
下图为一个partition的索引示意图：

Kafka的分布式实现

Kafka的通讯协议

Kafka的Producer、Broker和Consumer之间采用的是一套自行设计基于TCP层的协议，根据业务需求定制，而非实现一套类似Protocol Buffer的通用协议。
基本数据类型：
- 定长数据类型：int8,int16,int32和int64，对应到Java中就是byte, short, int和long。
- 变长数据类型：bytes和string。变长的数据类型由两部分组成，分别是一个有符号整数N(表示内容的长度)和N个字节的内容。其中，N为-1表示内容为null。bytes的长度由int32表示，string的长度由int16表示。
- 数组：数组由两部分组成，分别是一个由int32类型的数字表示的数组长度N和N个元素。

Kafka通讯的基本单位是Request/Response
基本结构：
RequestOrResponse => MessageSize (RequestMessage | ResponseMessage)

名称

类型

描述

MessageSize

int32

表示RequestMessage或者ResponseMessage的长度

RequestMessage

ResponseMessage

—

表示Request或者Response的内容

通讯过程：

客户端打开与服务器端的Socket

往Socket写入一个int32的数字(数字表示这次发送的Request有多少字节)

服务器端先读出一个int32的整数从而获取这次Request的大小

然后读取对应字节数的数据从而得到Request的具体内容

服务器端处理了请求后，也用同样的方式来发送响应。

RequestMessage结构:
RequestMessage => ApiKey ApiVersion CorrelationId ClientId Request

名称	类型	描述
ApiKey	int16	表示这次请求的API编号
ApiVersion	int16	表示请求的API的版本，有了版本后就可以做到后向兼容
CorrelationId	int32	由客户端指定的一个数字唯一标示这次请求的id，服务器端在处理完请求后也会把同样的CorrelationId写到Response中，这样客户端就能把某个请求和响应对应起来了。
ClientId	string	客户端指定的用来描述客户端的字符串，会被用来记录日志和监控，它唯一标示一个客户端。
Request	-	Request的具体内容。

ResponseMessage结构:
ResponseMessage => CorrelationId Response

名称	类型	描述
CorrelationId	int32	对应Request的CorrelationId。
Response	-	对应Request的Response，不同的Request的Response的字段是不一样的。

Kafka采用是经典的Reactor(同步IO)模式，也就是1个Acceptor响应客户端的连接请求，N个Processor来读取数据，这种模式可以构建出高性能的服务器。
Message:Producer生产的消息,键-值对
Message => Crc MagicByte Attributes Key Value

名称	类型	描述
CRC	int32	表示这条消息(不包括CRC字段本身)的校验码
MagicByte	int8	表示消息格式的版本，用来做后向兼容，目前值为0
Attributes	int8	表示这条消息的元数据，目前最低两位用来表示压缩格式
Key	bytes	表示这条消息的Key，可以为null
Value	bytes	表示这条消息的Value。Kafka支持消息嵌套，也就是把一条消息作为Value放到另外一条消息里面。

MessageSet:用来组合多条Message，它在每条Message的基础上加上了Offset和MessageSize
MessageSet => [Offset MessageSize Message]

名称	类型	描述
Offset	int64	它用来作为log中的序列号，Producer在生产消息的时候还不知道具体的值是什么，可以随便填个数字进去
MessageSize	int32	表示这条Message的大小
Message	-	表示这条Message的具体内容，其格式见上一小节。

Request/Respone和Message/MessageSet的关系：

Request/Response是通讯层的结构，和网络的7层模型对比的话，它类似于TCP层。

Message/MessageSet定义的是业务层的结构，类似于网络7层模型中的HTTP层。Message/MessageSet只是Request/Response的payload中的一种数据结构。

备注：Kafka的通讯协议中不含Schema，格式也比较简单，这样设计的好处是协议自身的Overhead小，再加上把多条Message放在一起做压缩，提高压缩比率，从而在网络上传输的数据量会少一些。

数据传输的事务定义

at most once: 最多一次,这个和JMS中"非持久化"消息类似.发送一次,无论成败,将不会重发.
at least once: 消息至少发送一次,如果消息未能接受成功,可能会重发,直到接收成功.
exactly once: 消息只会发送一次.
- at most once: 消费者fetch消息,然后保存offset,然后处理消息;当client保存offset之后,但是在消息处理过程中出现了异常,导致部分消息未能继续处理.那么此后"未处理"的消息将不能被fetch到,这就是"at most once".
- at least once: 消费者fetch消息,然后处理消息,然后保存offset.如果消息处理成功之后,但是在保存offset阶段zookeeper异常导致保存操作未能执行成功,这就导致接下来再次fetch时可能获得上次已经处理过的消息,这就是"at least once"，原因offset没有及时的提交给zookeeper，zookeeper恢复正常还是之前offset状态.
- exactly once: kafka中并没有严格的去实现(基于2阶段提交,事务),我们认为这种策略在kafka中是没有必要的.
注：通常情况下"at-least-once"是我们首选.(相比at most once而言,重复接收数据总比丢失数据要好).