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参数
如何实现因果关系消息的顺序行
- Kafka 主题设置单分区，也就是 1 个分区(不建议，丧失了 Kafka 多分区带来的高吞吐量和负载均衡的优势)
- 2.基于个别字段进行分区
4.避免消息丢失
消息丢失：
Kafka只对已提交的消息做持久化工作保存
提交不成功：网络抖动，消息不合格kafka拒绝接受
总之，职责在于producer，不要使用 producer.send(msg)，用producer.send(msg, callback) apiConsumer消费消息丢失：
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：消费者组机制，同时实现了消息队列模型和发布/订阅模型。
消费者组中的实例个数，最好与订阅主题的分区数相同，否则多出的实例只会被闲置。一个分区只能被一个消费者实例订阅。
