第一节 kafka 基础知识

Apache Kafka 不仅仅是消息引擎系统，还是一个分布式流处理平台。

要点

简单介绍
基本概念
分区
避免消息丢失
拦截器
rebalance

1.基本介绍

kafka主要有两大应用:
1）构造实时流数据管道，它可以在系统或应用之间可靠地获取数据。 (相当于message queue)
2）构建实时流式应用程序，对这些流数据进行转换或者影响。 (就是流处理，通过kafka stream topic和topic之间内部进行变化)

Kafka作为一个集群，运行在一台或者多台服务器上；Kafka 通过 topic 对存储的流数据进行分类。
每条记录中包含一个key，一个value和一个timestamp（时间戳）。
Kafka有四个核心的API:

The Producer API 允许一个应用程序发布一串流式的数据到一个或者多个Kafka topic。
The Consumer API 允许一个应用程序订阅一个或多个 topic ，并且对发布给他们的流式数据进行处理。
The Streams API 允许一个应用程序作为一个流处理器，消费一个或者多个topic产生的输入流，然后生产一个输出流到一个或多个topic中去，在输入输出流中进行有效的转换。
The Connector API 允许构建并运行可重用的生产者或者消费者，将Kafka topics连接到已存在的应用程序或者数据系统。比如，连接到一个关系型数据库，捕捉表（table）的所有变更内容。

2. 基本概念

Record:消息，指Kafka处理对象
Topic:主题，用来承载消息的容器
Partition:分区，一个有序不变的消息队列，一个主题下可以有多个分区
Offset:消息位移，表示分区中每条信息的位置，是一个单调递增不变的值
Replica,副本，数据冗余机制(Replication)。
-- 领导者副本(Leader Replica)：对外提供服务，与客户端进行交互
-- 追随者副本(Follower Replica)：不能与外界进行交互，只是被动地追随领导者副本
Producer:生产者，向主题发布新消息的应用程序
Consumer:消费者，向主题订阅新消息的应用程序
Consumer Offset:消费者位移，表示消费者消费进度
Consumer Group:消费者组，多个消费者实例共同组成的一个组，同时消费多个分区来实现高吞吐。
Rebalance:重平衡，消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。它是Kafka消费者端实现高可用的重要手段

副本的工作机制：生产者总是向领导者副本写消息；而消费者总是从领导者副本读消息；至于追随者副本，它只做一件事：向领导者副本发送请求，请求领导者把最新生产的消息发给它，这样它能保持与领导者的同步。这样保证了数据的持久化和消息不丢失。

3.分区

主题-->分区-->消息
生产者将消息发送到主题，消费者订阅主题，而主题下是有不同分区了，消息是挂在不同的分区之下的。一个分区只能有一个消费者，不能出现多个消费者同时订阅一个分区。

Kafka 的三层消息架构：

第一层是主题层，每个主题可以配置 M 个分区，而每个分区又可以配置 N 个副本
第二层是分区层，每个分区的 N 个副本中只能有一个充当领导者角色，对外提供服务；其他 N-1 个副本是追随者副本，只是提供数据冗余之用
第三层是消息层，分区中包含若干条消息，每条消息的位移从 0 开始，依次递增。最后，客户端程序只能与分区的领导者副本进行交互

image.png

其实分区的作用就是提供负载均衡的能力，或者说对数据进行分区的的主要原因，就是为了实现系统的伸缩性。不同的分区放在不同的节点上，数据的读写针对分区这个粒度进行的。这样可以通过增加新节点实现增加系统的吞吐量。

消息分区策略：
分区策略：轮询策略（默认）、随即策略、按消息键保序策略、其他策略（如：基于地理位置进行分区）
自定义分区策略需要，编写一个具体的类，实现org.apache.kafka.clients.producer.Partitioner接口,然后设置partitioner.class参数

如何实现因果关系消息的顺序行

1. Kafka 主题设置单分区，也就是 1 个分区(不建议，丧失了 Kafka 多分区带来的高吞吐量和负载均衡的优势)
2.基于个别字段进行分区

4.避免消息丢失

消息丢失：
Kafka只对已提交的消息做持久化工作保存
提交不成功：网络抖动，消息不合格kafka拒绝接受
总之，职责在于producer，不要使用 producer.send(msg)，用producer.send(msg, callback) api
Consumer消费消息丢失：
1）维持先消费消息（阅读），再更新位移（书签）的顺序
2）如果是多线程异步处理消费消息，Consumer 程序不要开启自动提交位移，而是要应用程序手动提交位移

解决方案：

不要使用 producer.send(msg)，而要使用 producer.send(msg, callback)
设置acks=all。acks是producer的一个参数，设置成all代表所有的broker都接收到信息，才算是已提交消息
设置retries位一个较大值，代表重试次数（网络抖动）
设置unclean.leader.election.enable=false。Broker参数，如果一个落后的borker变成leader，必然会造成消息丢失
设置replication.factor >= 3。Broker参数，备份数，数据冗余避免丢失
设置 min.insync.replicas > 1。Broker参数，这只消息至少呗写入多少个副本才算是已提交
确保replication.factor > min.insync.repicas 。如果两个相等只要有一个副本机挂了，整个分区将无法正常工作
设置enable.auto.commit=false。consumer的参数，确保消费完再提交

5.拦截器

Kafka 拦截器分为生产者拦截器和消费者拦截器，都支持链。
生产者拦截器要实现org.apache.kafka.clients.producer.ProducerInterceptor

消费者拦截器：org.apache.kafka.clients.consumer.ConsumerInterceptor

6.幂等性和事务

消息投递语义：

最多一次：消息可能丢失，但绝对不会重复
至少一次：消息不会丢失，但可能会重复
精确一次：消息不会丢失，也不会重复

Kafka:默认至少一次，那么Kafka如何做到精确一次？
幂等性和事务！！！

幂等性producer：
很简单就设置enable.idempotence=ture
注意：
1）只能保证单分片的幂等性
2）会话幂等性，不能实现跨会话幂等性
事务型producer：
1）首先开启幂等性：enable.idempotence=ture
2）其次设置 Producer 端参数 transctional.id
事务型 Producer的事务 API: initTransaction、beginTransaction、commitTransaction 和 abortTransaction，它们分别对应事务的初始化、事务开始、事务提交以及事务终止.

Consumer需要设置隔离级别：
solation.level
1）read_uncommitted：默认读未提交
2）read_committed:读已提交

7.rebalance

Rebalance发生的时机有三个
1）组成员数据量发生变化
2）订阅主题数量发生变化
3）订阅主题的分区数发生变化
其中第一个最常见，后面两个通常是运维的主动操作，无法避免。主要还是针对组成员数量减少的情况。增加一般也是人为主动的。

那么如何避免因为参数或逻辑不合理而导致的成员退出，与之相关的主要参数
1）session.timeout.ms,推荐设置6s
2）heartbeat.interval.ms,推荐设置2s
3）max.poll.interval.ms,推荐设置比你的业务逻辑处理要长
4）GC参数，避免频繁的FULL GC

重平衡过程是如何通知到其他消费者实例的？
靠消费者端的心跳线程（Heartbeat Thread）
消费者定期的发生心跳请求到Broker端的协调者，以表明他还活着。当协调者决定开启新一轮平衡后，他会将“rebalance_in_progress”封装进心跳请求的响应中，返还给消费者实例。当消费者实例发现心跳响应中包含了“rebanlance_in_progress”，就能立马知道冲平生又开始了。
heartbeat.interval.ms控制重平衡通知的频率

8.Consumer Group

Consumer Group ：Kafka提供的可扩展且具有容错性的消息者机制。

消费者组的重要特征：
A：组内可以有多个消费者实例（Consumer Instance）。
B：消费者组的唯一标识被称为Group ID，组内的消费者共享这个公共的ID。
C：消费者组订阅主题，主题的每个分区只能被组内的一个消费者消费
D：消费者组机制，同时实现了消息队列模型和发布/订阅模型。

消费者组中的实例个数，最好与订阅主题的分区数相同，否则多出的实例只会被闲置。一个分区只能被一个消费者实例订阅。