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
跨会话事物对齐