【kafka】kafka基础架构

梦里梦外; 2023-10-12 18:10 9阅读 0赞

#### 文章目录 ####

*  1、kafka简介
 *  2、kafka的特性
 *  3、kafka的应用场景
 *  4、kafka架构（重点）
 *   *  4.1、broker
     *  4.2、topic
     *  4.3、partition
     *  4.4、offset
     *  4.5、producer
     *  4.6、consumer
     *  4.7、consumer group
     *  4.8、leader
     *  4.9、follower
     *  4.10、rebalance
 *  5、对kafka架构的几点解释
 *  6、几种MQ对比
 *  7、 kafka的吞吐量为什么这么高？
 *   *  7.1、顺序读写磁盘
     *  7.2、page cache
     *  7.3、零拷贝
     *  7.4、分区分段

## 1、kafka简介 ##

Kafka最初由Linkedin公司开发，是一个分布式的、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常用于web/nginx日志、访问日志、消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

## 2、kafka的特性 ##

*  高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒；
 *  可扩展性：kafka集群支持热扩展；
 *  持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止丢失；
 *  容错性：允许集群中的节点失败(若分区副本数量为n,则允许n-1个节点失败)；
 *  高并发：单机可支持数千个客户端同时读写；

## 3、kafka的应用场景 ##

*  日志收集：一个公司可以用Kafka收集各种服务的log，通过kafka以统一接口开放给各种消费端，例如hadoop、Hbase、Solr等。
 *  消息系统：解耦生产者和消费者、缓存消息等。
 *  用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索记录、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
 *  运营指标：Kafka也经常用来记录运营监控数据。
 *  流式处理

## 4、kafka架构（重点） ##

![在这里插入图片描述][13615cf6f02742ce8f4f0c05df8f5581.png]

整体来看，kafka架构中包含四大组件：生产者、消费者、kafka集群、zookeeper集群

### 4.1、broker ###

kafka集群包含一个或多个服务器，每个服务器节点称为一个broker。

### 4.2、topic ###

每条发布到kafka集群的消息都有一个类别，这个类别称为topic，其实就是将消息按照topic来分类，topic就是逻辑上的分类，同一个topic的数据既可在同一个broker上也可以在不同的broker节点上

### 4.3、partition ###

分区，每个topic被物理划分为一个或多个分区，每个分区在物理上对应一个文件夹，该文件夹里面存储了这个分区的所有消息和索引文件。在创建topic时可以指定partition数量，生产者将消息发送到topic时，消息会根据分区策略追加到分区文件的末尾，属于顺序写磁盘，因此效率非常高（经验证，顺序写磁盘效率比随机写内存还要高，这是Kafka高吞吐率的一个很重要的保证）

![在这里插入图片描述][463edf5852674b83b00157a06dcaab4d.png]

上面提到分区策略，所谓分区策略就是决定生产者将消息发送到哪个分区的算法？

*  Kafka 为我们提供了默认的分区策略，同时它也支持自定义分区策略。
 *  kafka允许为每条消息设置一个key，一旦消息被定义了 Key，
 *  那么就可以保证同一个 Key 的所有消息都进入到相同的分区，
 *  这种策略属于自定义策略的一种，被称作"按消息key保存策略"，或Key-ordering 策略。

同一主题topic的多个partition分区可以部署在不同的机器上，以此来实现kafka的伸缩性。同一个partition的数据是有序的，但topic主题下多个partition之间在消费数据时不能保证有序性，在需要严格保证消息顺序性的场景下，可以将partition数设为1，但是这种做法的缺点就是降低吞吐量，一般来说，只需要保证每个分区的有序性，再对消息设置key来保证相同的key消息落入同一个分区，就可以满足绝大多数场景。

### 4.4、offset ###

partition中的每条消息都被标记了一个序号，这个序号表示消息在partition中的偏移量，称为offset，每一条消息在partition都有唯一的offset，消费者可以通过指定offset来指定要消费的消息。

正常情况下，消费者在消费完一条消息后会递增offset，准备去消费下一条消息，但也可以将offset设成一个较小的值，重新消费一些消费过的消息，可见offset是由consumer控制的，consumer想消费哪一条消息就消费哪一条消息，所以kafka broker是无状态的，它不需要标记哪些消息被消费过。

### 4.5、producer ###

生产者，生产者发送消息到指定的topic下，消息再根据分配规则append到某个partition的末尾。

### 4.6、consumer ###

消费者，消费者从topic中消费数据。

### 4.7、consumer group ###

消费者组，每个consumer属于一个特定的consumer group，可为每个consumer指定consumer group，若不指定则属于默认group。

同一topic的一条消息只能被同一个consumer group内的一个consumer消费，但多个consumer group可同时消费这一消息。这也是kafka用来实现一个topic消息的广播和单播的手段，如果需要实现广播，一个consumer group内只放一个消费者即可，要实现单播，将所有的消费者放到同一个consumer group即可。

用consumer group还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。

### 4.8、leader ###

每个partition有多个副本，其中有且仅有一个作为leader，leader会负责所有的客户端读写操作。

### 4.9、follower ###

follower不对外提供服务，只与leader保持数据同步，如果leader失效，则选举一个follower来充当新的leader。当follower与leader挂掉、卡住或者同步太慢，leader会把这个follower从ISR列表中删除，重新创建一个follower。

### 4.10、rebalance ###

同一个consumer group下有多个消费者互相协调消费工作，我们这样想，一个topic分为多个分区，一个consumer group里面的所有消费者合作，一起去消费所订阅的某个topic下的所有分区（每个消费者消费部分分区），kafka会将该topic下的所有分区均匀的分配给consumer group下的每个消费者，如下图：

![在这里插入图片描述][2285958fc3064c88ab78c6376fb98a18.png]

Rebalance表示"重平衡"，consumer group内某个消费者挂掉后，其他消费者自动重新分配订阅主题分区的过程，是 Kafka 消费者端实现高可用的重要手段。如下图Consumer Group A中的C2挂掉，C1会接收P1和P2，以达到重新平衡。同样的，当有新消费者加入consumer group，也会触发重平衡操作。

## 5、对kafka架构的几点解释 ##

*  一个典型的kafka集群中包含若干producer，若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干consumer group，以及一个zookeeper集群。kafka通过zookeeper协调管理kafka集群，选举分区leader，以及在consumer group发生变化时进行rebalance。
 *  kafka的topic被划分为一个或多个分区，多个分区可以分布在一个或多个broker节点上，同时为了故障容错，每个分区都会复制多个副本，分别位于不同的broker节点，这些分区副本中（不管是leader还是follower都称为分区副本），一个分区副本会作为leader，其余的分区副本作为follower。

leader负责所有的客户端读写操作，follower不对外提供服务，仅仅从leader上同步数据，当leader出现故障时，其中的一个follower会顶替成为leader，继续对外提供服务。

*  对于传统的MQ而言，已经被消费的消息会从队列中删除，但在Kafka中被消费的消息也不会立马删除，在kafka的server.propertise配置文件中定义了数据的保存时间，当文件到设定的保存时间时才会删除。

# 数据的保存时间(单位:小时，默认为7天)
     
    log.retention.hours=168

因为Kafka读取消息的时间复杂度为O(1)，与文件大小无关，所以这里删除过期文件与提高Kafka性能并没有关系，所以选择怎样的删除策略应该考虑磁盘以及具体的需求。

*  点对点模式 VS 发布订阅模式

传统的消息系统中，有两种主要的消息传递模式：点对点模式、发布订阅模式

①点对点模式

生产者发送消息到queue中，queue支持存在多个消费者，但是对一个消息而言，只可以被一个消费者消费，并且在点对点模式中，已经消费过的消息会从queue中删除不再存储。

②发布订阅模式

生产者将消息发布到topic中，topic可以被多个消费者订阅，且发布到topic的消息会被所有订阅者消费。而kafka就是一种发布订阅模式。

*  消费端 PULL和PUSH

①Push方式：由消息中间件主动地将消息推送给消费者；

②Pull方式：由消费者主动向消息中间件拉取消息；

## 6、几种MQ对比 ##

<table> 
 <thead> 
  <tr> 
   <th align="left">比较项</th> 
   <th align="left">ActiveMQ</th> 
   <th align="left">RabbitMQ</th> 
   <th align="left">RocketMQ</th> 
   <th align="left">Kafka</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">所属社区/公司</td> 
   <td align="left">Apache</td> 
   <td align="left">Mozilla Public License</td> 
   <td align="left">阿里巴巴</td> 
   <td align="left">Apache</td> 
  </tr> 
  <tr> 
   <td align="left">成熟度及授权</td> 
   <td align="left">成熟/开源</td> 
   <td align="left">成熟/开源</td> 
   <td align="left">比较成熟/开源</td> 
   <td align="left">成熟/开源</td> 
  </tr> 
  <tr> 
   <td align="left">开发语言</td> 
   <td align="left">java</td> 
   <td align="left">Erlang</td> 
   <td align="left">java</td> 
   <td align="left">Scala&amp;java</td> 
  </tr> 
  <tr> 
   <td align="left">客户端支持语言</td> 
   <td align="left">Java、C/C++、Python、PHP、Perl、.net等</td> 
   <td align="left">官方支持Erlang，java，Ruby等，社区产出多种语言API，几乎支持所有常用语言</td> 
   <td align="left">Java、C++</td> 
   <td align="left">官方支持java，开源社区有多语言版本，如PHP，Python，Go，C/C++，Ruby等</td> 
  </tr> 
  <tr> 
   <td align="left">协议支持</td> 
   <td align="left">OpenWire、STOMP、REST、XMPP、AMQP</td> 
   <td align="left">多协议支持:AMQP，XMPP，SMTP，STOMP</td> 
   <td align="left">自己定义的一套(社区提供JMS–不成熟)</td> 
   <td align="left">自有协议，社区封装了HTTP协议支持</td> 
  </tr> 
  <tr> 
   <td align="left">HA</td> 
   <td align="left">基于ZooKeeper + LevelDB的Master-Slave实现方式</td> 
   <td align="left">master/slave模式，master提供服务，slave仅作备份(冷备)</td> 
   <td align="left">支持多Master模式，多Master多Slave模式，异步复制模式、同步双写</td> 
   <td align="left">支持replica机制，leader宕掉后，备份自动顶替，并重新选举leader(基于Zookeeper)</td> 
  </tr> 
  <tr> 
   <td align="left">数据可靠性</td> 
   <td align="left">Master/slave，有较低的概率丢失数据</td> 
   <td align="left">可以保证数据不丢，有slave用作备份</td> 
   <td align="left">支持异步实时刷盘，同步刷盘，同步复制，异步复制</td> 
   <td align="left">数据可靠，且有replica机制，有容错容灾能力</td> 
  </tr> 
  <tr> 
   <td align="left">单机吞吐量</td> 
   <td align="left">万级</td> 
   <td align="left">万级</td> 
   <td align="left">十万级，支撑高吞吐</td> 
   <td align="left">十万级，高吞吐，一般配合大数据类的系统进行实时数据计算、日志采集等场景</td> 
  </tr> 
  <tr> 
   <td align="left">消息延迟</td> 
   <td align="left">毫秒级</td> 
   <td align="left">微秒级</td> 
   <td align="left">毫秒级</td> 
   <td align="left">毫秒级以内</td> 
  </tr> 
  <tr> 
   <td align="left">流量控制</td> 
   <td align="left"></td> 
   <td align="left">基于Credit-Based算法，是内部被动触发的保护机制，作用于生产者层面。</td> 
   <td align="left"></td> 
   <td align="left">支持client和user级别，通过主动设置可将流控作用于生产者或消费者。</td> 
  </tr> 
  <tr> 
   <td align="left">持久化能力</td> 
   <td align="left">默认内存，正常关闭时将内存中未处理的消息持久化文件，如果使用JDBC策略，则入数据库</td> 
   <td align="left">内存、文件，支持数据堆积。但堆积反过来影响吞吐量</td> 
   <td align="left">磁盘文件</td> 
   <td align="left">磁盘文件。只要磁盘容量够，可以做到无限消息堆积</td> 
  </tr> 
  <tr> 
   <td align="left">负载均衡</td> 
   <td align="left">支持</td> 
   <td align="left">支持</td> 
   <td align="left">支持</td> 
   <td align="left">支持</td> 
  </tr> 
  <tr> 
   <td align="left">管理界面</td> 
   <td align="left">一般</td> 
   <td align="left">较好</td> 
   <td align="left">命令行界面</td> 
   <td align="left">官方只提供命令行版，yahoo开源自己的web管理界面</td> 
  </tr> 
  <tr> 
   <td align="left">部署方式及难易</td> 
   <td align="left">独立/容易</td> 
   <td align="left">独立/容易</td> 
   <td align="left">独立/容易</td> 
   <td align="left">独立/容易</td> 
  </tr> 
  <tr> 
   <td align="left">功能支持</td> 
   <td align="left">MQ领域的功能较为完备</td> 
   <td align="left">基于Erlang开发，并发能力很强，性能极好，时延很低</td> 
   <td align="left">MQ功能较为完善，还是分布式的，扩展性好</td> 
   <td align="left">功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集方面被大规模使用</td> 
  </tr> 
 </tbody> 
</table>

## 7、 kafka的吞吐量为什么这么高？ ##

### 7.1、顺序读写磁盘 ###

Kafka是将消息持久化到本地磁盘中的，一般人会认为磁盘读写性能差，可能会对Kafka性能提出质疑。实际上不管是内存还是磁盘，快或慢的关键在于寻址方式，磁盘分为顺序读写与随机读写，内存一样也分为顺序读写与随机读写。基于磁盘的随机读写确实很慢，但基于磁盘的顺序读写性能却很高，一般而言要高出磁盘的随机读写三个数量级，一些情况下磁盘顺序读写性能甚至要高于内存随机读写，这里给出著名学术期刊 ACM Queue 上的一张性能对比图：

![在这里插入图片描述][6c5462dd8f2f4ef59f5c5e12b9935d6b.png]

### 7.2、page cache ###

为了优化读写性能，Kafka利用了操作系统本身的Page Cache，就是利用操作系统自身的内存而不是JVM空间内存。这样做是因为，

> JVM中一切皆对象，对象的存储会带来额外的内存消耗；

> 使用JVM会受到GC的影响，随着数据的增多，垃圾回收也会变得复杂与缓慢，降低吞吐量；

另外操作系统本身对page cache做了大量优化，通过操作系统的Page Cache，Kafka的读写操作基本上是基于系统内存的，读写性能也得到了极大的提升。

### 7.3、零拷贝 ###

零拷贝是指Kafka利用 linux 操作系统的 “zero-copy” 机制在消费端做的优化。首先来看一下消费端在消费数据时，数据从broker磁盘通过网络传输到消费端的整个过程：

> 操作系统从磁盘读取数据到内核空间（kernel space）的page cache；

> 应用程序读取page cache的数据到用户空间（user space）的缓冲区；

> 应用程序将用户空间缓冲区的数据写回内核空间的socket缓冲区（socket buffer）；

> 操作系统将数据从socket缓冲区复制到硬件（如网卡）缓冲区；

![在这里插入图片描述][8330d4dcf87d43b7b2b2a6f239b7e1a8.png]

整个过程如上图所示，这个过程包含4次copy操作和2次系统上下文切换，而上下文切换是CPU密集型的工作，数据拷贝是I/O密集型的工作，性能其实非常低效。零拷贝就是使用了一个名为sendfile()的系统调用方法，将数据从page cache直接发送到Socket缓冲区，避免了系统上下文的切换，消除了从内核空间到用户空间的来回复制。从上图可以看出，"零拷贝"并不是说整个过程完全不发生拷贝，而是站在内核的角度来说的，避免了内核空间到用户空间的来回拷贝。

### 7.4、分区分段 ###

Kafka的message是按topic分类存储的，topic中的数据又是按照一个一个的partition即分区存储到不同broker节点。每个partition对应了操作系统上的一个文件夹，partition实际上又是按照segment分段存储的。这也非常符合分布式系统分区分桶的设计思想。

通过这种分区分段的设计，Kafka的message消息实际上是分布式存储在一个一个小的segment中的，每次文件操作也是直接操作的segment。为了进一步的查询优化，Kafka又默认为分段后的数据文件建立了索引文件，就是文件系统上的.index文件。这种分区分段+索引的设计，不仅提升了数据读取的效率，同时也提高了数据操作的并行度。

总之，Kafka采用顺序读写、Page Cache、零拷贝以及分区分段等这些设计，再加上在索引方面做的优化，另外Kafka数据读写也是批量的而不是单条的，使得Kafka具有了高性能、高吞吐、低延时的特点。

[13615cf6f02742ce8f4f0c05df8f5581.png]: https://img-blog.csdnimg.cn/13615cf6f02742ce8f4f0c05df8f5581.png
[463edf5852674b83b00157a06dcaab4d.png]: https://img-blog.csdnimg.cn/463edf5852674b83b00157a06dcaab4d.png
[2285958fc3064c88ab78c6376fb98a18.png]: https://img-blog.csdnimg.cn/2285958fc3064c88ab78c6376fb98a18.png
[6c5462dd8f2f4ef59f5c5e12b9935d6b.png]: https://img-blog.csdnimg.cn/6c5462dd8f2f4ef59f5c5e12b9935d6b.png
[8330d4dcf87d43b7b2b2a6f239b7e1a8.png]: https://img-blog.csdnimg.cn/8330d4dcf87d43b7b2b2a6f239b7e1a8.png