网站建设要不要工商注册互站网源码商城

当前位置： 首页 > news >正文

网站建设要不要工商注册,互站网源码商城,交易网站开发文档,长沙地铁最新招聘500人Kafka简介 Kafka是一个由Scala和Java编写的企业级的消息发布和订阅系统#xff0c;最早是由Linkedin公司开发#xff0c;最终开源到Apache软件基金会的项目。Kafka是一个分布式的#xff0c;支持分区的#xff0c;多副本的和多订阅者的高吞吐量的消息系统#xff0c;被广…Kafka简介 Kafka是一个由Scala和Java编写的企业级的消息发布和订阅系统最早是由Linkedin公司开发最终开源到Apache软件基金会的项目。Kafka是一个分布式的支持分区的多副本的和多订阅者的高吞吐量的消息系统被广泛应用在应用解耦、异步处理、限流削峰和消息驱动等场景。本文将针对Kafka的架构和相关组件进行简单的介绍。在介绍Kafka的架构之前我们先了解一下Kafk的核心概念。 Kafka核心概念 在详细介绍Kafka的架构和基本组件之前需要先了解一下Kafka的一些核心概念。 Producer消息的生产者负责往Kafka集群中发送消息 Consumer消息的消费者主动从Kafka集群中拉取消息。 Consumer Group每个Consumer属于一个特定的Consumer Group新建Consumer的时候需要指定对应的Consumer Group ID。 BrokerKafka集群中的服务实例也称之为节点每个Kafka集群包含一个或者多个Broker一个Broker就是一个服务器或节点。 Message通过Kafka集群进行传递的对象实体存储需要传送的信息。 Topic消息的类别主要用于对消息进行逻辑上的区分每条发送到Kafka集群的消息都需要有一个指定的Topic消费者根据Topic对指定的消息进行消费。 Partition消息的分区Partition是一个物理上的概念相当于一个文件夹Kafka会为每个topic的每个分区创建一个文件夹一个Topic的消息会存储在一个或者多个Partition中。 Segment一个partition当中存在多个segment文件段分段存储每个Segment分为两部分.log文件和 .index 文件其中 .index 文件是索引文件主要用于快速查询.log 文件当中数据的偏移量位置 .log文件存放Message的数据文件在Kafka中把数据文件就叫做日志文件。一个分区下面默认有n多个.log文件分段存储。一个.log文件大默认1G消息会不断追加在.log文件中当.log文件的大小超过1G的时候会自动新建一个新的.log文件。 .index文件存放.log文件的索引数据每个.index文件有一个对应同名的.log文件。 后面我们会对上面的一些核心概念进行更深入的介绍。在介绍完Kafka的核心概念之后我们来看一下Kafka的对外提供的基本功能组件及架构设计。 Kafka API 如上图所示Kafka主要包含四个主要的API组件 Producer API 应用程序通过Producer API向Kafka集群发送一个或多个Topic的消息。 Consumer API 应用程序通过Consumer API向Kafka集群订阅一个或多个Topic的消息并处理这些Topic下接收到的消息。 Streams API 应用程序通过使用Streams API充当流处理器Stream Processor从一个或者多个Topic获取输入流并生产一个输出流到一个或者多个Topic能够有效地将输入流进行转变后变成输出流输出到Kafka集群。 Connect API 允许应用程序通过Connect API构建和运行可重用的生产者或者消费者大数据培训能够把kafka主题连接到现有的应用程序或数据系统。Connect实际上就做了两件事情使用Source Connector从数据源如DB中读取数据写入到Topic中然后再通过Sink Connector读取Topic中的数据输出到另一端如DB以实现消息数据在外部存储和Kafka集群之间的传输。
Kafka架构 接下来我们将从Kafka的架构出发重点介绍Kafka的主要组件及实现原理。Kafka支持消息持久化消费端是通过主动拉取消息进行消息消费的订阅状态和订阅关系由客户端负责维护消息消费完后不会立刻删除会保留历史消息一般默认保留7天因此可以通过在支持多订阅者时消息无需复制多分只需要存储一份就可以。下面将详细介绍每个组件的实现原理。

1. Producer Producer是Kafka中的消息生产者主要用于生产带有特定Topic的消息生产者生产的消息通过Topic进行归类保存在Kafka 集群的Broker上具体的是保存在指定的partition 的目录下以Segment的方式.log文件和.index文件进行存储。
2. Consumer Consumer是Kafka中的消费者主要用于消费指定Topic的消息Consumer是通过主动拉取的方式从Kafka集群中消费消息消费者一定属于某一个特定的消费组。
3. Topic Kafka中的消息是根据Topic进行分类的Topic是支持多订阅的一个Topic可以有多个不同的订阅消息的消费者。Kafka集群Topic的数量没有限制同一个Topic的数据会被划分在同一个目录下一个Topic可以包含1至多个分区所有分区的消息加在一起就是一个Topic的所有消息。
4. Partition 在Kafka中为了提升消息的消费速度可以为每个Topic分配多个Partition这也是就之前我们说到的Kafka是支持多分区的。默认情况下一个Topic的消息只存放在一个分区中。Topic的所有分区的消息合并起来就是一个Topic下的所有消息。每个分区都有一个从0开始的编号每个分区内的数据都是有序的但是不同分区直接的数据是不能保证有序的大数据培训因为不同的分区需要不同的Consumer去消费每个Partition只能分配一个Consumer但是一个Consumer可以同时一个Topic的多个Partition。 Replica机制 Kafka 为分区引入了多副本Replica机制通过增加副本数量可以提升容灾能力。同一分区的不同副本中保存的是相同的消息在同一时刻副本之间并非完全一样副本之间是“一主多从”的关系其中 leader 副本负责处理读写请求follower 副本只负责与 leader 副本的消息同步。当 leader 副本出现故障时从 follower 副本中重新选举新的 leader 副本对外提供服务。 如上图所示Kafka 集群中有4个 broker某个主题中有3个分区且副本因子即副本个数也为3如此每个分区便有1个 leader 副本和2个 follower 副本。
5. Consumer Group Kafka中的每一个Consumer都归属于一个特定的Consumer Group如果不指定那么所有的Consumer都属于同一个默认的Consumer Group。Consumer Group由一个或多个Consumer组成同一个Consumer Group中的Consumer对同一条消息只消费一次。每个Consumer Group都有一个唯一的ID即Group ID也称之为Group Name。Consumer Group内的所有Consumer协调在一起订阅一个Topic的所有Partition且每个Partition只能由一个Consuemr Group中的一个Consumer进行消费但是可以由不同的Consumer Group中的一个Consumer进行消费。如下图所示 在层级关系上来说Consumer好比是跟Topic对应的而Consumer就对应于Topic下的Partition。Consumer Group中的Consumer数量和Topic下的Partition数量共同决定了消息消费的并发量且Partition数量决定了最终并发量因为一个Partition只能由一个Consumer进行消费。当一个Consumer Group中Consumer数量超过订阅的Topic下的Partition数量时Kafka会为每个Partition分配一个Consumer多出来的Consumer会处于空闲状态。当Consumer Group中Consumer数量少于当前定于的Topic中的Partition数量是单个Consumer将承担多个Partition的消费工作。如上图所示Consumer Group B中的每个Consumer需要消费两个Partition中的数据而Consumer Group C中会多出来一个空闲的Consumer4。总结下来就是同一个Topic下的Partition数量越多同一时间可以有越多的Consumer进行消费消费的速度就会越快吞吐量就越高。同时Consumer Group中的Consumer数量需要控制为小于等于Partition数量且最好是整数倍如124等。
6. Segment 考虑到消息消费的性能Kafka中的消息在每个Partition中是以分段的形式进行存储的即每1G消息新建一个Segment每个Segment包含两个文件.log文件和.index文件。之前我们已经说过.log文件就是Kafka实际存储Producer生产的消息而.index文件采用稀疏索引的方式存储.log文件中对应消息的逻辑编号和物理偏移地址offset以便于加快数据的查询速度。.log文件和.index文件是一一对应成对出现的。下图展示了.log文件和.index文件在Partition中的存在方式。
   Kafka里面每一条消息都有自己的逻辑offset相对偏移量以及存在物理磁盘上面实际的物理地址便宜量Position也就是说在Kafka中一条消息有两个位置offset相对偏移量和position磁盘物理偏移地址。在kafka的设计中将消息的offset作为了Segment文件名的一部分。Segment文件命名规则为Partition全局的第一个Segment从0开始后续每个segment文件名为上一个Partition的最大offsetMessage的offset非实际物理地偏移地址实际物理地址需映射到.log中后面会详细介绍在.log文件中查询消息的原理。数值最大为64位long大小由20位数字表示前置用0填充。
   上图展示了.index文件和.log文件直接的映射关系通过上图我们可以简单介绍一下Kafka在Segment中查找Message的过程   1.根据需要消费的下一个消息的offset这里假设是7使用二分查找在Partition中查找到文件名小于一定要小于因为文件名编号等于当前offset的文件里存的都是大于当前offset的消息当前offset的最大编号的.index文件这里自然是查找到了00000000000000000000.index。   2.在.index文件中使用二分查找找到offset小于或者等于指定offset这里假设是7的最大的offset这里查到的是6然后获取到index文件中offset为6指向的Position物理偏移地址为258。   3.在.log文件中从磁盘位置258开始顺序扫描直到找到offset为7的Message。 至此我们就简单介绍完了Segment的基本组件.index文件和.log文件的存储和查询原理。但是我们会发现一个问题.index文件中的offset并不是按顺序连续存储的为什么Kafka要将索引文件设计成这种不连续的样子这种不连续的索引设计方式称之为稀疏索引Kafka中采用了稀疏索引的方式读取索引kafka每当.log中写入了4k大小的数据就往.index里以追加的写入一条索引记录。使用稀疏索引主要有以下原因   (1)索引稀疏存储可以大幅降低.index文件占用存储空间大小。   (2)稀疏索引文件较小可以全部读取到内存中可以避免读取索引的时候进行频繁的IO磁盘操作以便通过索引快速地定位到.log文件中的Message。
7. Message Message是实际发送和订阅的信息是实际载体Producer发送到Kafka集群中的每条消息都被Kafka包装成了一个Message对象之后再存储在磁盘中而不是直接存储的。Message在磁盘中的物理结构如下所示。 On-disk format of a message offset : 8 bytes message length : 4 bytes (value: 4 1 1 8(if magic value 0) 4 K 4 V) crc : 4 bytes magic value : 1 byte attributes : 1 byte timestamp : 8 bytes (Only exists when magic value is greater than zero) key length : 4 bytes key : K bytes value length : 4 bytes value : V bytes其中key和value存储的是实际的Message内容长度不固定而其他都是对Message内容的统计和描述长度固定。因此在查找实际Message过程中磁盘指针会根据Message的offset和message length计算移动位数以加速Message的查找过程。之所以可以这样加速因为Kafka的.log文件都是顺序写的往磁盘上写数据时就是追加数据没有随机写的操作。 8.Partition Replicas 最后我们简单聊一下Kafka中的Partition Replicas分区副本机制0.8版本以前的Kafka是没有副本机制的。创建Topic时可以为Topic指定分区也可以指定副本个数。kafka 中的分区副本如下图所示 Kafka通过副本因子replication-factor控制消息副本保存在几个Broker服务器上一般情况下副本数等于Broker的个数且同一个副本因子不能放在同一个Broker中。副本因子是以分区为单位且区分角色主副本称之为Leader任何时刻只有一个从副本称之为 Follower可以有多个处于同步状态的副本叫做in-sync-replicas(ISR)。Leader负责读写数据Follower不负责对外提供数据读写只从Leader同步数据消费者和生产者都是从leader读写数据不与follower交互因此Kafka并不是读写分离的。同时使用Leader进行读写的好处是降低了数据同步带来的数据读取延迟因为Follower只能从Leader同步完数据之后才能对外提供读取服务。 如果一个分区有三个副本因子就算其中一个挂掉那么只会剩下的两个中选择一个leader如下图所示。但不会在其他的broker中另启动一个副本因为在另一台启动的话必然存在数据拷贝和传输会长时间占用网络IOKafka是一个高吞吐量的消息系统这个情况不允许发生。如果指定分区的所有副本都挂了Consumer如果发送数据到指定分区的话将写入不成功。Consumer发送到指定Partition的消息会首先写入到Leader Partition中写完后还需要把消息写入到ISR列表里面的其它分区副本中写完之后这个消息才能提交offset。 如上图所示第一条消息的 offsetLogStartOffset为0最后一条消息的 offset 为8offset 为9的消息用虚线框表示代表下一条待写入的消息。日志文件的 HW 为6表示消费者只能拉取到 offset 在0至5之间的消息而 offset 为6的消息对消费者而言是不可见的。 数据同步 分区中的所有副本统称为 ARAssigned Replicas。所有与 leader 副本保持一定程度同步的副本包括 leader 副本在内组成ISRIn-Sync ReplicasISR 集合是 AR 集合中的一个子集。 与 leader 副本同步滞后过多的副本不包括 leader 副本组成 OSROut-of-Sync Replicas由此可见ARISROSR。在正常情况下所有的 follower 副本都应该与 leader 副本保持一定程度的同步即 ARISROSR 集合为空。 Leader 副本负责维护和跟踪 ISR 集合中所有 follower 副本的滞后状态当 follower 副本落后太多或失效时leader 副本会把它从 ISR 集合中剔除。默认情况下当 leader 副本发生故障时只有在 ISR 集合中的副本才有资格被选举为新的 leader。 HW 是 High Watermark 的缩写俗称高水位它标识了一个特定的消息偏移量offset消费者只能拉取到这个 offset 之前的消息。 LEO 是 Log End Offset 的缩写它标识当前日志文件中下一条待写入消息的 offset。 linux 服务下创建分区 去服务器kafka文件夹下创建相应的kafka topic创建命令如下bin/kafka-topics.sh –create –zookeeper localhost:2181 –replication-factor \({n} --partitions \){m} –topic \({topic}, 其中 \){n}→副本个数kafka单机情况下为1集群一般为3 \({m}→分区个数一般为10 \){topic}→需要创建的topic:BAYONET_VEHICLEPASS_NOTIFY_JSON_TOPIC、XSINK_PLATE_ALARM_NOTIFY、XSINK_PERSON_NOTIFY_ALARM、ORIGIN_BAYONET_VEHICLEPASS_NOTIFY_JSON_TOPIC Kafka Tool 简单使用 在这里插入图片描述 kafka 客户端发送流程 kafka 高并发实践设计