(1)Kafka设计架构综述

最新推荐文章于 2023-03-25 14:33:40 发布

Bug型程序员

最新推荐文章于 2023-03-25 14:33:40 发布

阅读量1.3k

点赞数 2

分类专栏： kafka 文章标签： kafka 分布式 hadoop 中间件消息队列

本文链接：https://blog.csdn.net/qq_35494772/article/details/120878564

版权

kafka 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

Kafka设计原理总结

(1)Kafka设计架构综述

(2)Kafka中生产者工作机制详解

(3)Kafka 消费者工作机制详解

(4)Kafka高效读写原理、选举过程和事务实现

1.Kafka介绍

(1)基本概念

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者的所有动作流数据。这种动作如：

活动数据：网站用户行为数据，例如PV(页面浏览量)，UV(用户访问量)
运营数据：监控系统性能指标(cpu利用率、负载，内存使用率，磁盘利用率，IO性能)

这些 数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决，特性如下：

海量数据不可变
实时处理

对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。 Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消费。

(2)常用应用场景

解耦： 消息队列在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。可独立扩展两端处理过程，只需要它门遵守同样接口约束。将Kafka作为整个系统的中枢，负责在任意两个系统之间传递数据。
可恢复性：即使一个处理消息的进程挂掉， 加入队列中的消息可以在系统恢复后被处理。
冗余： 如果数据处理失败，除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，这样规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中， 在把一个消息从队列中删除之前，需要系统明确指出该消息已经被处理完毕，从而确保数据被保存直到使用完毕。
缓冲：有助于控制和优化数据流传输速度，解决生产和消费消息速度不一致( 一般生产者速度大于消费者)。
扩展性：因为消息队列解耦了处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。
灵活性 & 峰值处理能力： 浏览突发场景并不常见，但如果时刻处理峰值比较浪费资源。使用消息队列能够 使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
顺序保证：大部分消息队列本来就是排序的，Kafka能保证一个Partition内的消息的有序性。
异步通信：消息队列提供了异步处理机制， 允许用户把一个消息放入队列，但并不立即处理它，这样可以保留多条消息。

2.消息传送模式

(1) 点对点传送模式(Push)

消息持久在队列中，没有消费者时消息一直保留队列中
消息只能被消费一次，可保证消息有序处理，但一条消息只能被一个消费者使用。
消息代理将消息推送(Push)到消费者后，标记消息已被消费，但无法保证消费的处理语义。
Push 消息发送速率是由broker决定，目标是尽可能发布消息，很容易造成consumer来不及处理消息。

(2) 发布订阅消息传递(Poll)

消息被持久在Topic中，当你发布一个消息，所有订阅这个topic的服务都能得到消息，即订阅者都能得到这个消息的拷贝。
消费者可订阅多个topic，同一条数据可被多个消费者消费，数据被消费后不会立马删除。
Kafka采用拉取模型(Poll)，消费者控制消费速度，消费者可以按照任意偏移量进行消费。
当没有消息时，消费者采用轮询方式咨询是否有新消息。

3.结构基本概念

(1)Kafka集群概念

①Broker(服务器)

一个Broker就是Kafka集群中的 一个节点，多个Broker组成了Kafka集群。 一个 broker 可以容纳多个 topic。

②Topic（主题/表）

Kafka 把同一类数据进行汇总，每一类数据的集合就是一个Topic， 相当于表。
生产者Producer将同一类型的数据写入同一个Topic，消费者Consumer从同一个Topic中消费该同类数据。
Topic逻辑上的概念，因为实际存放在Topic的数据存放在 一个或多个partition，而 文件夹会以主题名+分区名r命名。

③Partition（分区）

Topic有多个分区，相当于数据分成多份，存放在不同分区中。
分区是 物理概念，每个分区对应一个文件夹，存储分区的数据和索引文件。
一个topic 可以分布到多个 broker上， 一个 topic 可以分为多个partition，每个partition是一个有序的队列；分区是有序、不可修改的消息队列， 每个分区内消息是有序的。 仅保证同一分区内消息有序存储，不保证Topic整体（多个分区之间）有序

④Replication（副本）

作为partition的副本， 一个 topic 的每个分区都有若干个副本， 一个 leader 和若干个 follower 。

⑤Producer(消息生产者）：向Broker发布消息的客户端

⑥Consumer(消息消费者）：消费Broker中信息的客户端

⑦Consumer Group(CG，消费者组：配置有 相同 group.id 的任意一个消费者构成一个逻辑消费者。

CG消费者组是为了加快消费的读取速度的一个模型， 一个消费者组中的多个消费者可以并行消费同一个Topic中的数据。
多个CG可以消费同一个Topic，这些消费者组之间是平等的， 即同一条消息可同时被多个消费者组消费。
同一个CG消费者组中的多个Consumer消费者之间是竞争关系，也就是说 同一条消息在一个消费者组中只能被一个消费者所消费。

⑧Zookeeper

Zookeeper负责保存Kafka的元数据
负责Kafka的集群管理，包括配置管理、动态扩展、Broker负载均衡、Leader选举、以及CG变化时重新平衡

(2)传输单位

①Message

消息是Kafka通讯的基本单位， 有一个固定长度的消息头和一个可变长度的消息体(payload)构成。在Java客户端中又称之为 记录(Record)。

CRC32: CRC32校验和，4个字节。
magic: Kafka服务程序协议版本号 ，用于做兼容。1个字节。
attributes: 该字段占1字节，其中低两位用来表示压缩方式，第三位表示时间戳类型（0表示LogCreateTime，1表示LogAppendTime），高四位为预留位置，暂无实际意义。
timestamp: 消息时间戳，当magic>0 时消息头必须包含该字段。8个字节。
key-length: 消息key长度，4个字节。
key: 消息key实际数据。
payload-length: 消息实际数据长度，4个字节。
payload: 消息实际数据在实际存储一条消息还包括12字节的额外开销（LogOverhead）:
- 消息的偏移量: 8字节，类似于消息的Id。
- 消息的总长度: 4字节