(5)Kafka原理和高可用介绍

最新推荐文章于 2024-08-18 23:52:56 发布

Bug型程序员

最新推荐文章于 2024-08-18 23:52:56 发布

阅读量2.6k

点赞数 1

分类专栏： Hadoop 文章标签： kafka big data hadoop 消息队列分布式计算

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

版权

Hadoop 专栏收录该内容

9 篇文章 3 订阅

订阅专栏

专栏目录

(1)大数据和应用场景介绍

(2)大数据技术综述总结

(3)HDFS原理与高可用技术原理介绍

(4)Yarn架构、资源管理原理和运维技术介绍

(5)Kafka原理和高可用介绍

1.Kafka介绍

(1)基本概念

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

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

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

海量数据不可变
实时处理

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

(2)常用应用场景

作为一个 消息队列，Kafka避免了交叉信息传递中消息传递混乱的现象，作为一个中间数据收集、汇总层，对多种消息传递场景进行解耦，并且自身具有相当优越的冗余机制和高扩展性。

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

2.Kafka结构概念

(1) Broker（代理）

一个Broker就是Kafka集群中的 一个节点，多个Broker组成了Kafka集群。

(2) Topic（主题/表）

Kafka 把同一类数据进行汇总，每一类数据的集合就是一个Topic， 相当于表。
生产者Producer将同一类型的数据写入同一个Topic，消费者Consumer从同一个Topic中消费该同类数据。
Topic逻辑上的概念，使用者只用知道Topic即可，无需关系数据存于何处。

(3) Partition（分区）

Topic有多个分区，相当于数据分成多份，存放在不同分区中。
分区是 物理概念，每个分区对应一个文件夹，存储分区的数据和索引文件。
分区是有序、不可修改的消息队列， 每个分区内消息是有序的。

(4) Replication（副本）

分区的副本，每个副本存储在不同的Broker中。

(5) Producer（消息生产者）

向Broker发布消息的客户端

(6) Consumer（消息消费者）

消费Broker中信息的客户端

(7) Consumer Group（CG，消费者组）

将多个消费者作为一个群体

(8) Zookeeper

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

(9) 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字节