kafka快速上手
Kafka介绍
MQ的作用
MQ：MessageQueue，消息队列，是一种FIFO先进先出的数据布局，消息则是跨历程传递的数据。一个典型的MQ系统，会将消息由消息的生产者发送到MQ进行排队，然后根据肯定的顺序交由消息的消费者进行处置惩罚。
MQ的作用主要有下面3个方面：
异步：异步可以或许进步系统的响应速率、吞吐量
解耦：1.服务之间进行解耦，才可以减少服务之间的影响，进步系统团体的稳定性及可扩展性。2.另外解耦后可以实现数据分发。生产者发送一个消息后，可以由一个大概多个消费者进行消费，并且消费者的增长大概减少对生产者没有影响
削峰：以稳定的系统资源应对突发的流量打击
Kafka产物介绍
Kafka是目前最具有影响力的开源MQ产物，官网地点：https://kafka.apache.org/
apache Kafka最初由linkelin开发并于2011年开源，他主要办理大规模数据的及时流式处置惩罚和数据管道题目。
Kafka是一个分布式的发布-订阅消息系统，可以快速地处置惩罚高吞吐量的数据流，并将数据及时地分发到多个消费者种。Kafka消息系统由多个broker（服务器）组成，这些broker可以在多个数据中心之前分布式部署，以提供高可用性和容错性。
Kafka使用高效的数据存储和技术管理，可以或许轻松地处置惩罚TB级别的数据量。其长处包括高吞吐量、低延迟、可扩展性、持久性、容错性等。
Kafka在企业级应用种被广泛应用，包括及时流处置惩罚、日志聚合、监控和数据分析等方面。同时Kafka还可以与其他大数据工具集成，如Hadoop、Spark和Storm等，构建一个完整的数据处置惩罚生态系统。
Kafka特点
Kafka最初诞生于LinkedIn公司，其核心作用就是用来网络并处置惩罚庞大复杂的应用日志。一个典型的日志聚合应用场景如下：
业务场景决定了产物的特点：
1.数据吞吐量很大：需要可以或许快速网络海量日志
2.集群容错性高：允许集群中少量节点瓦解
3.功能不消太复杂：Kafka的操持目标是高吞吐、低延迟和可扩展，主要关注消息传递而不是消息处置惩罚。Kafka并没有支持死信队列、顺序消息等高级功能
4.允许少量数据丢失：在海量的应用日志中，少量的日志丢失是不会影响结果的。服务的稳定性要求比数据安全高
Kafka快速上手
Kafka底子工作机制是消费发送者可以将消息发送到指定的topic，而消费消费者，可以从指定的topic上消费消息。
现实操作：1.创建一个topic；2.启动一个消息发送者，往topic发送消息；3.启动消息消费者从topic消费消息
Kafka的消费传递机制
Kafka体系，以下概念需要知道
客户端client：包括消息生产者和消息消费者
消费者组：每个消费者可以指定一个所属的消费者组，雷同消费者组的消费者共同构成一个逻辑消费者组。每一个消息会被多个感兴趣的消费者组消费，但是在每一个消费者组内部，一个消息只会被消费一次。
服务端Broker：一个Kafka服务器就是一个Broker
话题Topic：这是一个逻辑概念，一个Topic被认为是业务寄义雷同的一组消息。客户端都是通过绑定Topic来生产大概消费自己感兴趣的话题
分区partition：topic只是一个逻辑概念，而partition就是现实存储消息的组件、每个partition就是一个queue队列布局。全部消息以FIFO先进先出的顺序保存在这些partition分区中。
理解Kafka的集群工作机制
对于Kafka这样一个追求消费吞吐量的产物来说，集群基本上是必备的。kafka的集群布局大体是这样的：
消息尽大概均匀的分布到不同的partition操持原因：
1.Kafka操持需要支持海量的数据，而这样大的数据量，一个Broker是存不下的，那就拆分成多个partition，每个broker只存一部分数据，这样极大的扩展了集群的吞吐量。
2.每个partition保留了一部分的消息副本，如果放到一个broker上，就容易出现单点故障。所以就给每个partition操持follower节点，进行数据备份，从而包管数据安全。另外多备份的partition操持也进步了读取消息时的并发度
3.在同一个Topic的多个partition中，会产生一个partition作为leader。这个leader partition会负责响应客户端的哀求，并将数据往其他partition分发。
Kafka集群的消息流转模子
Kafka客户端小型流转流程
Kafka提供了两套客户端API，HighLevel API和LowLevel API。HighLevel API封装了Kafka的运行细节，使用起来比力简朴，是企业开发过程中最常用的客户端API。而LowLevel API则需要客户端自己管理Kafka的运行细节，partition，offset这些数据都是由客户端自行管理，这层API功能更灵活，但是使用起来非常复杂，也更容易出错。只在极少数对性能要求非常极致的场景才会偶尔使用。
Kafka提供了非常简朴的API，只需要引入一个Maven依赖即可
客户端工作机制
消费者分组消费机制
在consumer中，都需要指定一个GROUP_ID_CONFIG属性，这表现当前Consumer所属的消费者组。
生产者往topic下发消息时，会尽量均匀的将消息发送到Topic下的各个partition当中，而这个消息，会向全部订阅该topic的消费者推送，推送时，每个consumer Group中只会推送一份。也就是同一个消费者组中的多个消费者实例，只共同消费一个消息副本。而不同消费者组之间，会重复消费消息副本，这就是消费者组的作用。与之相关的还有offset偏移量，这个偏移量表现每个消费者组在每个partition中已经消费处置惩罚的进度，在Kafka中，可以看到消费者组的offset记录环境。
生产者拦截器机制
生产者拦截器机制允许客户端在生产者在消息发送到Kafka集群之前，对消息进行拦截，甚至可以修改消息内容。这里涉及到producer中指定的一个参数：INTERCEPTOR_CLASSES_CONFIG
消费序列化机制
producer指定了两个属性KEY_SERIALIZER_CLASS_CONFIG和VALUE_SERIALIZER_CLASS_CONFIG,对于这两个属性，在ProducerConfig中都有配套的说明属性。通过这两个参数，可以指定消息生产者怎样将消息的key和value序列化成二进制数据。
在Kafka的消息定义中，key和value的作用是不同的：
key是用来进行分区的可选项。Kafka通过key来判定消息要分发到哪个partition。如果没有填写key，Kafka会自动选择partition。如果填写了key，那么会通过声明的Serializer序列化接口，将key转换成一个byte[]数组，然后对key进行hash，选择partition。这样可以包管key雷同的消息会分配到雷同的partition中。
value是业务上比力关心的消息，Kafka同样需要将value对象通过声明的Serializer序列化接口，将value转换成一个byte[]数组，这样才气较好的在网络上传输value信息，以及将value信息落盘到操作系统的文件当中。
在Kafka中，对于常用的一些底子数据范例，都已经提供了对应的实现类。在自己进行序列化机制时，需要考虑的是怎样用二进制来形貌业务数据。例如对于一个通常的pojo范例，可以将他的属性拆分为两种范例，一种范例是定长的底子范例，比如integer，long,double等。这些底子范例转化成二进制数组都是定长的。这类属性可以直接转成序列化数组，在反序列化时，只要按照定长去读取二进制数据就可以反序列化；另一种是不定长的浮动范例，比如string大概基于string的json范例等，这种浮动范例的底子数据转化成二进制数组，长度都是不肯定的，对于这类数据，通常的处置惩罚方式都是先往二进制数组中写入一个定长的数据的长度数据，然后再继续写入数据本身，这样，反序列化时，就可以先读取一个定长的长度，再按照这个长度去读取对应长度的二进制数据，这样就能读取到数据的完整二进制内容。
“渔与鱼”序列化机制是在高并发场景中非常重要的一个优化机制。高效的系列化实现可以或许极大的提拔分布式系统的网络传输以及数据落盘的能力。
消息分区路由机制
producer会根据消息的key选择partition，一个消费者组会共同消费一个topic下的多个partition中的同一套消息副本，在producer中，可以指定一个partition来对消息进行分配。
Kafka默认提供了三种分区分配计谋：
range计谋：比如一个topic有10个partition（0-9）一个消费者组下有3个consumer（consumer1-3）.range计谋就会将分区0-3分给一个consumer，4-6给一个consumer，7-9给一个consumer
round-robin计谋：轮询分配计谋，可以理解为在consumer中一个一个轮流分配分区。比如0，3，6，9分区给一个Consumer1;1,4,7分区给一个consumer2；然后2，5，8给一个consumer3
sticky计谋：粘性计谋，这个计谋有两个原则：1.在开始分区时，尽量保持分区的分配均匀。2.分区的分配尽大概的与上一次分配的保持一致
生产者消息缓存机制
Kafka生产者为了克制高并发哀求对服务端造成过大压力，每次发消息时并不是一条一条发往服务端，而是增长了一个高速缓存，将消息会合到缓存后，批量进行发送。这种缓存机制也是高并发处置惩罚时非常常用的一种机制。Kafka的消息缓存机制涉及到KafkaProducer中的两个关键组件：accumulator和sender
此中RecordAccumulator就是Kafka生产者的消息累加器。Kafkaproducer要发送的消息都会在reocrdaccumulator中缓存起来，然后再分批发送给Kafkabroker.在RecordAccumulator中，会针对每一个partition，维护一个Deque双端队列，这些dequeue队列基本上是和Kafka服务器端的topic下的partition对应的。每个dequeue里会放入若干个ProducerBatch数据。Kafkaproducer每次发送的消息，都会根据key分配到对应的deque队列中，然后每个消息都会保存在这些队列中的某一个producerbatch中。而消息分发的规则是由上面的partition组件完成的。
生产者发送应答机制
这是在开发过程中比力重要的一个机制，涉及到的，就是producer端一个属性ACKS_CONFIG。这个属性更大的作用在于包管消息的安全性，尤其在replica-factor备份因子比力大的Topic中，尤为重要。
asks=0，生产者不关系broker端有没有将消息写入到partition，只发送消息就不管了。吞吐量是最高的，但是数据安全性是最低的。
asks=all or -1，生产者需要等broker端的全部partition都写完了才气得到返回结果，这样数据是最安全的，但是每次发消息需要等候更长的时间，吞吐量是最低的。
asks=1，则是一种相对中和的计谋。leader partition在写完自己的消息后，就向生产者返回结果
生产者消息幂等性
当producer的acks=1 or -1时，producer每次发送消息都是需要获取broker端返回的recordmetadata的，这个过程中就需要两次跨网络哀求。如果要包管消息安全，那么对于每个消息，这两次网络哀求就必须要求是幂等的。但是网络是不靠谱的，在高并发场景下，往往没有办法包管幂等，producer会重复发送多条消息到broker中，Kafka怎样包管无论发送多少次重复数据，broker端都只保留一条消息，这就是消费生产者的幂等性题目。
分布式数据传递过程中的三个语义：at-least-once:至少一次；at-most-once:最多一次；exactly-once:准确一次
Kafka为了包管消息发送的exactly-once语义，增长了几个概念：
PID：每个新的Producer在初始化的过程中就会被分配一个唯一的PID。这个PID是对用户不可见的
Sequence Number：对于每个PID，这个producer针对partition会维护一个SequenceNumber。这是一个重0开始单调递增的数字。当producer要往同一个partition发送消息时，这个sequencenumber就会加1，然后会随着消息一起发给broker
broker会针对每个(pid,partition)维护一个序列号（SN），只有当对应的sequencenumber=SN+1时，broker才会吸收消息，同时将SN更新为SN+1.否则就认为消息以及写入了，不需要再重复写入。
生产者消费压缩机制以及消息事物机制
当生产者往broker发送消息时，还会对每个消息进行压缩，从而低落producer到broker的网络数据传输压力，同时也低落了broker的数据存储压力。具体涉及到producerconfig中的COMPRESSION_TYPE_CONFIG配置项
生产者消息事物
通过生产者消息幂等性题目，可以或许办理单生产者消息写入单分区的幂等性题目，无法办理一次发多条消息题目，这个时候就出现了一个事物机制，包管这一批消息最好同时乐成的保持幂等性，大概这一批消息同时失败，这样生产者就可以开始进行团体重试，消息不至于重复。针对这个题目，卡夫卡引入了消息事物机制，者涉及到producer的几个API：
Kafka的事物消息还会做两件事：
一个transactionld只会对应一个PID
跨会话事物对齐
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
