文章目录

  • Kafka简介
    • Kafka是什么
    • 消息队列
    • 消息队列的两种工作模式
      • 点对点模式
      • 发布/订阅模式
  • Kafka架构
  • Kafka消息存储机制
  • Kafka分区策略
  • Kafka数据可靠性保证
    • Kafka向producer发送ack确认的时机
    • ISR(in-sync replica set )
      • ack应答机制
  • Kafka中的故障处理
    • follower发生故障:
    • leader发生故障:

Kafka简介

Kafka是什么

Kafka是由Apache软件基金会开发的一个开源流处理平台,由Scala和Java编写。Kafka是一个分布式的基于发布/订阅模式的消息队列,相比于其他常见的消息队列,Kafka的特点是高吞吐量极高,主要应用于大数据实时处理领域。

消息队列

Kafka是一个常用的消息队列,消息队列就是在消息的传输过程中保存消息的容器。消息队列有很多种用途,可以用来给程序解耦合,可以让同步的程序变成异步,在运维和后台中,消息队列还会被用来削峰和限流。

下面举了一个消息队列的使用场景,让同步的程序变成异步运行。一个原本以同步方式进行运行的程序,用户填写注册表并提交,写入数据库成功后,系统调用发送短信接口发送短信,短信发送后用户会得到响应成功的返回信息。这种同步运行的方式有一个问题,就是调用短信接口的过程可能会耗费很多时间,所以会让用户等很久才能得到回复,然而其实用户注册信息写入数据库之后的步骤都已经不需要用户的介入了。面对这种场景,通过消息队列将同步处理变为异步处理可以很好的解决问题。用户注册信息写入数据库之后,将发送短信的请求写入消息队列暂存,然后发送短信的接口从消息队列中拿消息发短信,用户可以直接得到响应而不用一直等待短信发送完成后才能得到注册成功的信息。

这种异步的思想在前端框架ajax中也有体现。

消息队列的两种工作模式

点对点模式

消息生产者生产消息发送到Queue中,然后消息消费者从Queue中取出并且消费消息。消息被消费以后,Queue中不再有存储,所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者,但是对一个消息而言,只会有一个消费者可以消费。

发布/订阅模式

消息生产者(发布)将消息发布到topic中,同时有多个消息消费者(订阅)消费该消息。和点对点方式不同,发布到topic的消息会被所有订阅者消费,而且消费者消费数据之后不会清除消息。Kafka使用的就是这种模式

Kafka架构

下面是一个Kafka集群的架构图:
broker :
一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。

topic :
可以理解为一个队列,生产者和消费者面向的都是一个topic。

producer :
消息生产者,就是向kafka broker发消息的客户端。

consumer :
消息消费者,向kafka broker取消息的客户端。

consumer group (CG):
消费者组,由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据,一个分区只能由一个消费者消费;消费者组之间互不影响。所有的消费者都属于某个消费者组,即消费者组是逻辑上的一个订阅者。

partition:
为了实现扩展性,一个非常大的topic可以分布到多个broker(即服务器)上,一个topic可以分为多个partition,每个partition是一个有序的队列。

replica:
副本,为保证集群中的某个节点发生故障时,该节点上的partition数据不丢失,且kafka仍然能够继续工作,kafka提供了副本机制,一个topic的每个分区都有若干个副本,一个leader和若干个follower。

leader:
每个分区多个副本的“主”,生产者发送数据的对象,以及消费者消费数据的对象都是leader。

follower:
每个分区多个副本中的“从”,实时从leader中同步数据,保持和leader数据的同步。leader发生故障时,某个follower会成为新的follower。

Kafka消息存储机制

Kafka中消息是以topic进行分类的,生产者生产消息,消费者消费消息,都是面向topic的。
topic是逻辑上的概念。为了方便扩展,并提高吞吐量,Kafka将一个topic分为多个partition,partition是物理上的概念,每个partition对应于一个log文件,该log文件中存储的就是producer生产的数据。为提高可用性,Kafka还为每个partition增加若干副本,防止因为节点宕机而产生的消息丢失。

producer生产的数据会被不断追加到partition也就是log文件的末端,且每条数据都有自己的offset。消费者组中的每个消费者,都会实时记录自己消费到了哪个offset,以便出错恢复时,从上次的位置继续消费。

由于生产者生产的消息会不断追加到log文件末尾,为防止log文件过大导致数据定位效率低下,Kafka采取了分片和索引机制,将每个partition分为多个segment。每个segment对应两个文件,以.index为后缀名的文件和以.log为后缀名的文件。这些文件位于一个文件夹下,该文件夹的命名规则为:topic名称+分区序号。例如,first这个topic有三个分区,则其对应的文件夹为first-0、first-1、first-2。

index和log文件以当前segment的第一条消息的offset命名。index文件存储大量的索引信息,log文件存储大量的数据,索引文件中的元数据指向对应数据文件中message的物理偏移地址。下图为index文件和log文件的示意图:

Kafka分区策略

Kafka的分区就是将一个topic分成多个Partition进行存储,这种方式让Kafka集群的扩展性得到提高,每个Partition可以通过调整以适应它所在的机器,因此整个集群就可以适应任意大小的数据了。除了可以提高扩展性,通过分区还可以提高Kafka集群的并发性能,因为分区前consumer只能以topic为单位进行读写,分区后consumer可以以Partition为单位进行读写,Partition只是topic的一部分,所以这样设计让Kafka的并发性能非常好。

Kafka会将producer发送的数据封装成一个ProducerRecord对象。封装过程中需要设置分区策略。Kafka的分区策略一共有三种:

  1. 指明partition的情况下,直接将指明的值直接作为partiton值;
  2. 没有指明partition值但有key的情况下,将key的hash值与topic的partition数进行取余得到 partition 值;
  3. 使用round-robin算法,在既没有 partition 值又没有 key 值的情况下,第一次调用时随机生成一个整数(后面每次调用在这个整数上自增),将这个值与topic 可用的 partition 总数取余得到 partition 值。

Kafka数据可靠性保证

Kafka中的数据可靠性,指的是producer发送给Kafka的数据,不会丢失,也不会重复。

为保证producer正常发送数据,不受Kafka集群中节点变动的影响,可靠的将数据发送到指定的topic,topic的每个partition收到producer发送的数据后,都需要向producer发送ack(acknowledgement的缩写,确认收到),如果producer收到ack,就会进行下一轮的发送,否则重新发送数据。

Kafka向producer发送ack确认的时机

Kafka集群有很多的follower和一个leader节点,producer向Kafka集群发送数据后,各个节点会同步自己接收到的数据。Kafka在确保有follower与leader同步完成后,leader才会发送ack,这样才能保证如果发生leader宕机挂掉的情况,能迅速在follower中选举出新的leader。至于在leader发送ack时有多少follower完成同步,是有两种方案的,这两种方案和选举机制有关。方案一:有半数以上的follower同步完成,即可发送ack。方案二:全部的follower同步完成,才可以发送ack。

方案一的优点是,延迟低,因为不用等所有follower同步完成,但是缺点也非常明显,选举新的leader时,容忍n台节点的故障需要2n+1个副本。也就是说,这种方式虽然发送ack的延迟很低,但是Kafka集群中的各个节点需要存储更多的数据副本。

方案二的优点是,选举新的leader时,容忍n台节点的故障需要n+1个副本,但是缺点是延迟高。

面对以上两种方案,Kafka选择了第二种方案,原因是,同样为了容忍n台节点的故障,第一种方案需要2n+1个副本,而第二种方案只需要n+1个副本,而Kafka的每个分区都有大量的数据,第一种方案会造成大量数据的冗余。虽然第二种方案的网络延迟会比较高,但网络延迟对Kafka的影响较小。

ISR(in-sync replica set )

由于Kafka要等到全部的follower同步完成,才可以发送ack,那么很有可能会出现以下情景:leader收到数据,所有follower都开始同步数据,但有一个follower,因为某种故障,迟迟不能与leader进行同步,那leader就要一直等下去,直到它完成同步,才能发送ack。这种情况会让Kafka的效率大大降低,为了应对这种场景,Kafka设计了ISR。

Kafka的Leader维护了一个动态的ISR,全称是in-sync replica set ,意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后,leader就会给follower发送ack。如果follower长时间未向leader同步数据,则该follower将被踢出ISR。如果是Leader发生故障,Kafka就会通过Zookeeper从ISR中选举新的leader。

ack应答机制

对于某些不太重要的数据,对数据的可靠性要求不是很高,能够容忍数据的少量丢失,没必要等ISR中的follower全部接收成功。所以Kafka为用户提供了三种可靠性级别,用户根据对可靠性和延迟的要求进行权衡,选择不同的配置。acks有三种可用的参数配置,分别是0、1、-1:

acks=0:
producer不等待broker的ack,这一操作提供了一个最低的延迟,broker一接收到还没有写入磁盘就已经返回,当broker故障时有可能丢失数据。

acks=1:
producer等待broker的ack,partition的leader落盘成功后返回ack,如果在follower同步成功之前leader故障,那么将会丢失数据。

acks= -1:
producer等待broker的ack,partition的leader和follower全部落盘成功后才返回ack。但是如果在follower同步完成后,broker发送ack之前,leader发生故障,那么会造成数据重复。

默认情况下,acks会被设置为-1,避免数据丢失的情况。

Kafka中的故障处理

Kafka集群中,如果producer在发送数据时,如果follower和leader发生故障,那么集群就需要最一些故障处理,避免发生数据读取的混乱。

Kafka故障处理过程有两个概念:LEO和HW,他们是两个位置标识符。
LEO:每个副本的最后一个offset。
HW:所有副本中最小的LEO,HW之前的数据对Consumer可见,HW之后的数据对Consumer不可见。

follower发生故障:

follower发生故障后会被临时踢出ISR,待该follower恢复后,follower会读取本地磁盘记录的上次的HW,并将log文件高于HW的部分截取掉,从HW开始向leader进行同步。等该follower的LEO大于等于该Partition的HW,即follower追上leader之后,就可以重新加入ISR了。

leader发生故障:

leader发生故障之后,会从ISR中选出一个新的leader,之后,为保证多个副本之间的数据一致性,其余的follower会先将各自的log文件高于HW的部分截掉,然后从新的leader同步数据。

消息队列kafka知识总结相关推荐

  1. 光速入门消息队列Kafka

    文章目录 光速入门消息队列Kafka 消息队列 知识要点 2.1 背景.问题的产生 2.2 消息队列应运而生 2.3 消息队列的特点 认识kafka 知识要点 2.1 认识kafka 2.2 kafk ...

  2. 分布式消息队列 Kafka

    分布式消息队列 Kafka 2016-02-25 杜亦舒 Kafka是一个高吞吐量的.分布式的消息系统,由Linkedin开发,开发语言为scala 具有高吞吐.可扩展.分布式等特点 适用场景 活动数 ...

  3. 阿里云消息队列Kafka商业化:支持消息无缝迁移到云上

    摘要: 7月25日,阿里云宣布正式推出消息队列Kafka,全面融合开源生态.在兼容Apache生态的基础上,阿里云消息队列Kafka彻底解决了开源产品稳定性不足的痛点,可用性达99.9%,数据可靠性9 ...

  4. 阿里云正式推出消息队列Kafka:全面融合开源生态

    摘要: 在全面兼容Apache Kafka生态的基础上,消息队列Kafka彻底解决Apache Kafka稳定性不足的长期痛点,并且支持消息无缝迁移到云上. 近日,阿里云宣布正式推出消息队列Kafka ...

  5. 消息队列 Kafka的架构原理 (小白必看)

    最终大家会掌握 Kafka 中最重要的概念,分别是 Broker.Producer.Consumer.Consumer Group.Topic.Partition.Replica.Leader.Fol ...

  6. 消息队列 Kafka 的基本知识及 .NET Core 客户端

    前言 最新项目中要用到消息队列来做消息的传输,之所以选着 Kafka 是因为要配合其他 java 项目中,所以就对 Kafka 了解了一下,也算是做个笔记吧. 本篇不谈论 Kafka 和其他的一些消息 ...

  7. 一文搞定大数据消息队列Kafka

    文章目录 1.JMS+AMQP核心知识 1.1.什么是MQ中间件 1.2.使用场景 1.3.JMS消息服务和和常见核心概念 2.分布式流处平台Kafka核心概念 2.1.Kafka核心概念 2.2.特 ...

  8. 【中间件】大数据之分布式消息队列Kafka

    目录 Kafka设计动机 Kafka特点 Kafka设计架构 基本架构 Kafka各组件详解 Kafka关键技术点 典型应用场景       在大数据数据收集环节,需要构建数据流水线,其中一种方式可以 ...

  9. 基于Docker搭建分布式消息队列Kafka

    本文基于Docker搭建一套单节点的Kafka消息队列,Kafka依赖Zookeeper为其管理集群信息,虽然本例不涉及集群,但是该有的组件都还是会有,典型的kafka分布式架构如下图所示.本例搭建的 ...

  10. kafka创建topic_ELK-基础系列(六)-ELK加入消息队列-Kafka部署

    Kafka集群部署指南 一.前言 1.Kafka简介 Kafka是一个开源的分布式消息引擎/消息中间件,同时Kafka也是一个流处理平台.Kakfa支持以发布/订阅的方式在应用间传递消息,同时并基于消 ...

最新文章

  1. MySQL5.7.10多元复制功能搭建
  2. catia圆柱转化为圆台_浅析actran气动噪声仿真技术,以圆柱绕流气动噪声仿真为例...
  3. 【网络安全】Penelope:一款功能强大的Shell处理工具
  4. MySQL Workbench导出数据库
  5. resttemplate 设置请求头_Jmeter信息头管理器常用的三种传参格式
  6. svn-the working copy is locked due to a previous
  7. [2017.01.04] 经典排序算法思想及其实现
  8. 关于margin的数值是百分比,参照对象
  9. xampps mysql无法启动
  10. 二级c语言 办公软件高级应用,高级应用题库_计算机国二office高级应用考试的题目是从题库20套里抽其中一套还是别的题目_淘题吧...
  11. sql建表与gp建表语句
  12. O(lg m + lgn)时间复杂度求两个有序序列合并后第K大的数
  13. Oracle导出数据中的prompt,set feedback 等是什么意思
  14. css3中自适应边框图片运用
  15. 【Typecho主题】情侣博客Brave主题源码
  16. bzoj-2818 Gcd
  17. 自学大数据入门全套学习资料(视频+课程大纲+笔记)
  18. 8000401a错误解决方案(Excel)
  19. UG模具设计之汽车特斯拉车灯与后备箱规律边境构建技巧
  20. 再见!北京!再见!百度!

热门文章

  1. oracle聚合字符串,Oracle 聚合字符串
  2. arduino 土壤温湿度传感器_三分钟告诉你Arduino是什么
  3. 为什么要制定一些自己根本不想执行的计划?
  4. 使用字符流FileReader读取文本文
  5. SLAM_SLAM中一般是如何求解相机的运动的?
  6. 树的存储_ 双亲表示法 及 双亲孩子表示法
  7. 自动驾驶汽车如何解决复杂交互问题?清华联合MIT提出M2I方案
  8. 实操教程 | 深度学习pytorch训练代码模板(个人习惯)
  9. 2021 CVPR | 基于渐进感受局部区域推理的全方位监督点云分割
  10. 使用YOLO V4通过社交距离和口罩检测来缓解COVID