ToB企服应用市场:ToB评测及商务社交产业平台

标题: Kafka概论 [打印本页]

---

作者: 我可以不吃啊    时间: 2024-8-8 00:54
标题: Kafka概论
媒介

任何消息中间件，除了基础组件架构外，核心特性无非三个，消息可靠性、消息模子、吞吐量，本文要聊的正是这些东西，其余诸如API、下载安装、集群搭建等都是死的，而且会随着版本的变动而改变，这类东西针对不同版本，查官方文档即可。

目次
媒介
1.概述
1.1.特点
1.2.架构
2.消息模子
2.1.发布订阅模式
2.2.点对点
2.3.消息顺序
2.4.消息通报语义
2.6.事务
3.怎样包管吞吐量
3.1.顺序写
3.2.序列化
3.3.零拷贝

---

1.概述

1.1.特点

Kafka，一款具有高吞吐量、高可靠性的分布式消息中间件。其采用分布式架构、顺序写、序列化、零拷贝等机制包管了高吞吐量，数据自动落磁盘完成长期化来包管消息不会丢失。
1.2.架构

topic：
主题，消息的分类
partition：
分区，Kafka是一个分布式的消息中间件，同一个topic可以被拆成多个partition，不同的partition存储在不同的服务器节点上。分区是Kafka里的最小并行单位，一个消耗者可以消耗多个分区，一个分区可以被多个消耗者组里的消耗者消耗，但是一个分区不能同时被一个消耗者组里的多个消耗者消耗，紧张是为了克制重复消耗。

offset：
偏移量，Kafka会为每条消息分配一个偏移量，偏移量就是该消息的index，Kafka通过offset来对消息举行提取，同一个分区中的offset是唯一的。
record：
消息记录，Kafka中的消息以KV键值对的方式记录，被称为消息记录。
replication：
Kafka通过副本机制，包管消息的可靠性，同编号的分区的个数和副本数是一致的，一份消息可以被复制为多个副本，分开存储在同编号的不同分区中。同编号的分区间有主从关系，读写都针对主分区，从分区只负责举行数据同步。Kafka会维护一个ISR，里面会记录处于同步的分区，不同步的会从ISR中剔除，直到同步后再重新纳入。

2.消息模子

2.1.发布订阅模式

一条消息可以被多个消耗者消耗。
消耗者大概消耗者组可以去订阅某一个topic，该topic中的每一条消息都会推送给订阅的消耗者大概消耗者组。
同一个消耗者组的不同消耗者回去消耗同一个topic的不同分区，如果消耗者数目大于分区数目时，同一个分区允许被同一个消耗组多次消耗，只要不是同时并行消耗就行。

2.2.点对点

一条消息只能由一个消耗者消耗。

2.3.消息顺序

同一个topic下，单个分区中消息是有序的，和发送顺序一致。不同编号的分区间消息是无序的。
比如同一个topic的消息，A,B被存到了分区0中，C被存到了分区1中，那么消耗者消耗到的顺序可能是ABC，也可能是ACB，大概其它排列组合。
2.4.消息通报语义

Kafka支持多种消息通报语义：

• 最多一次，消息可能会丢失，永远不重复发送。
  
• 至少一次，消息不会丢失，但是可能会重复发送。
  
• 精确一次，包管消息被通报到服务端且在服务端不重复，精确一次必要生产者和消耗者一起来包管。
  

精确一次：
生产方必要包管：
发送方必要包管：
2.6.事务

Kafka的消息生产支持事务，是标准的两阶段提交模子。
如果对两阶段的事务模子不熟悉的同砚，可以移步博主的另一篇文章：
分布式事务__BugMan的博客-CSDN博客
kafka中的事务状态：

• 开启（Ongoing）：事务已经开启，但尚未提交或回滚。
  
• 预备提交（PreparingCommit）：事务已经发送了所有消息，并预备提交。
  
• 提交（Committing）：事务正在提交，即将把消息长期化到Kafka的主题中。
  
• 回滚（Aborting）：事务正在回滚，将抛弃该事务中所有尚未提交的消息。
  

Kafka事务的紧张流程：

• 开启事务：生产者在发送消息前调用beginTransaction()方法来开启一个事务。开启事务时，生产者会向事务协调器注册自己，并获取一个全局唯一的生产者ID和事务ID。
  
• 发送消息：生产者可以发送多个消息到不同的分区，这些消息将在同一个事务中。
  
• 预备提交：在所有消息都发送成功后，生产者调用commitTransaction()方法来预备提交事务。在这个阶段，生产者会将事务状态更新为“预备提交”，并向事务协调器发送“预提交”哀求。
  
• 事务协调器处置处罚：事务协调器吸收到“预提交”哀求后，会将该事务的状态更新为“预备提交”，并记录下生产者ID和事务ID。然后，事务协调器将“预提交”哀求发送给Kafka的其他Broker，并等待它们的相应。
  
• 提交或回滚：如果所有Broker都能成功担当事务的“预提交”哀求，那么事务协调器会向生产者发送“正式提交”哀求，表示可以提交事务。生产者收到“正式提交”哀求后，将所有消息长期化到Kafka的主题中。如果在预备提交阶段或提交阶段出现错误，生产者可以调用abortTransaction()方法来回滚事务。
  
• 竣事事务：事务完成后，生产者可以调用close()方法来关闭事务。这将会开释生产者的资源并终止与事务协调器的连接。
  

kafka的事务隔离级别：
默以为read_uncommitted，即脏读。现实利用时设置为read_committed，读已提交即可。
3.怎样包管吞吐量

3.1.顺序写

Kafka为了包管消息不丢失，会将消息写入磁盘来存储，消耗消息的时候再从磁盘中读出。众所周知，磁盘IO是很慢的动作，由于要寻道吗。以是对于磁盘IO来说比力好的一种优化方法就是将同类型的数据会合写在连续的存储空间上，减少寻道带来的时间开销。这种方式叫做顺序写，顾名思义将数据顺序写在连续的存储空间内。Kafka采用了这种方式来加速磁盘IO。总结起来就是一个partition就是一个文件，向partition追加写入，在消耗的时候就能包管数据的连续性。
kafka将来自Producer的数据，顺序追加在partition，partition就是一个文件，以此实现顺序写入。Consumer从broker读取数据时，由于自带了偏移量，接着上次读取的位置继续读，以此实现顺序读。

3.2.序列化

序列化和反序列化其实一张图就能讲明白：

MQ在网络上传输message时，将携带的数据序列化后举行传输会加速传输速度，由于序列化后的数据在网络传输种会具有以下几个长处：

• 报文更加紧凑，序列化后的二进制数据会比json之类的文本格式体积要小很多，自然报文的大小就更小。
  
• 不用依靠第三方依靠，像json转对象之类的操作通常必要去依靠第三方的JSON框架，直接用序列化的话可以克制对第三方的依靠。
  
• 解析速度更快，序列化过程无需解析数据，而 JSON 转对象必要解析 JSON 文本。JSON 解析涉及字符到数字的转换、字符串到对象的映射等处置处罚，相比直接转换二进制数据，解析过程较为复杂，因此在性能上较慢。
  

要注意的是以上长处是指多数情况下，序列化相较于JSON之类的文本解析存在的优势，少数极度的例子序列化不一定还存在以上优势。比如数据就传一个{"name":"zou"}之类的，序列化的报文由于某些形貌性的字节位置是固定要有的，终极的报文大小不一定比JSON的报文大小要小，解析速度也不一定有JSON解析快。但是在现实应用种我们传输的数据一定是一个相对复杂的对象，以是在现实业务场景种序列化是会存在以上的优势的。
Kafka的序列化和反序列化是在SDK内实现的，Kafka在SDK内提供了一套默认的序列化机制，也支持自定义序列化机制。这里就不睁开谈了，版本的更迭SDK种的API会有变化的，要用的时候查对应版本的官方手册更为稳妥。
3.3.零拷贝

零拷贝（Zero-Copy）是一种优化技能，旨在提高数据传输的效率和性能，特别是在文件传输和网络数据传输中。传统的数据传输方式涉及多次数据拷贝，而零拷贝通过克制不必要的数据拷贝操作，减少了数据传输的开销，从而提高体系的性能。
在传统的数据传输中，比方从磁盘读取文件并通过网络发送，通常涉及以下步骤：

• 将数据从磁盘读取到内核空间（Kernel Buffer）。
  
• 将数据从内核空间拷贝到用户空间（User Buffer）。
  
• 将数据从用户空间拷贝到网络缓冲区（Network Buffer）。
  
• 终极数据通过网络发送。
  

这种传统的数据传输方式涉及多次数据拷贝，每次拷贝都必要 CPU 到场，并且必要在内核空间和用户空间之间举行数据复制，导致了额外的开销和延迟。
零拷贝技能的紧张思想是克制不必要的数据拷贝，通过直接在内核空间和用户空间之间传输数据，从而减少 CPU 和内存的利用。
关于0拷贝更详细的内容异步博主的另一篇文章：
全网最清晰的零拷贝详解，看一遍就会__BugMan的博客-CSDN博客

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4