kafka:
- 集群模式，即便只有一个节点，也是集群
- 基于zookeeper的分布式消息系统，分布式流平台，并不单纯是个消息队列
- 具有高吞吐率、高性能、实时及高可靠等特点
基本概念：
- broker： 一个独立的kafka服务器，接受来自生产者的消息
- brkoer集群：若干个broker组合起来的集群
- Topic： 主题。一个虚拟的概念，代表消息的类型，一个主题可以有多个分区，分区存放在不同的broken上
- Partition： 分区。实际消息存储单位
- Producer： 消息生产者
- Consumer： 消息消费者
五大API：前三个常用
- Producers
- Consumers
- Stream Processors
- Connectors
- Admin
AdminClient API：
- AdmminClient：创建AdminClient客户端对象
- NewTopic：创建Topic
- CreateTopicsResult：创建Topic的返回结果
- ListTopicsResult：查询Topic列表
- ListTopicsOptions：查询Topic列表及选项
- DescribeTopicsResult：查询Topics
- DescribeConfigsResult：查询Topics配置项
Prodecers API：
发送模式：
同步发送、异步发送、异步回调发送
KafkaProducer:
- MetricConfig
- 加载负载均衡器
- 初始化Serializer
- 初始化RecordAccumulator，类似于计数器
- 启动newSender，守护线程
源码通知：
- Producer是线程安全的
- Producer并不是接到一条发一条
- Producer是批量发送，减少IO操作（一次写入大量数据），日志文件追加
producer.send(record):
- 计算分区：消息具体进入哪一个partition
- 计算批次：accumulator.append(),往待发送批次里增加记录
- 主要内容：
- 创建批次
- 向批次中追加记录
Producer发送原理解析：
- 直接发送：kafka的producer会直接把消息发送到分区leader的主机上，一般不会涉及到其他干预
- 负载均衡：没有自定义则默认，数据是可以被控制在哪个分区上的，由客户端决定。默认时为伪随机发送
- 异步发送：本身是Future对象（可以不获取），可以批量发送减少单次IO，增大吞吐量
消息传递保障：
依赖于Producer和Consumer共同实现，主要依赖于Producer
producer需要server接收到数据之后发出的确认接收的信号，此项配置就是指producer需要多少个这样的确认信号。代表了数据备份的可用性
1.最多一次：收到0到1次保障（速度最快）
2.至少一次：收到1到多次（其次）
3.正好一次：有且仅有一次
Consumer客户端操作
配置配置文件，然后设置订阅哪一个Topic或者几个，用循环批量拉取
在拉取时，可以设置offset自增，这样是最简单的使用方式，但处理数据失败后无法回滚
通过consumer.commitAsync()可以手动更新一个批次
注意事项：
- 单个分区的消息只能由ConsumerGroup中某个Consumer消费 即：一个分区的消息只能给一个Consumer，但一个Consumer可以从多个分区中拉取消息
- Consumer从分区中消费消息是顺序的，默认从头开始消费
- 单个ConsumerGroup会消费分区中的消息
最优：一个分区由一个Consumer去消费，充分利用资源性能
consumer.assign()制定订阅的分区
多线程情况：
并不是线程安全的，需要自行解决
经典模式：（新手建议）
简单来说，线程类自带consumer属性，也就是每一个线程对象都有consumer对象，这样便是线程安全的
但每个线程都需要一个consumer对象，创建和销毁都比较占资源
分发模式：（适合流式数据）
由一个consumer拉取消息，然后将数据分发给不同的线程
快速处理数据，但是因为无法监听线程回馈导致业务无法回滚
offset：
手动控制offset，当出现程序错误时，可重复消费一次
consumer.seek（）
- 第一次从0开始消费（一般情况）
- 比如一次消费了100条吗，则offet设置为101并且存入Redis
- 每次拉取之前从redis中获取最新的offset位置
- 每次从这个位置开始消费
Stream API：
基本概念：
- 处理分析存储在Kafka数据的客户端程序库
- Stream通过state store可以实现高效状态操作
- 支持原语Processor和高层抽象DSL
- 流及流处理器： 数据流，对数据进行处理的节点
- 流处理拓扑：流的走向，流程图
- 源处理器和Sink处理器：数据的源头，来源 数据的终点，出口
通过input主题和output主题来实现数据源和出
//创建流
Properties pros = .....
StreamsBuilder sB =....
KafkaStreams streams = new KafkaStreams（sB.build()，props）
streams.start();Connect API
Connect是Kafka流式计算的一部分
主要用来与其他中间件建立流式通道
支持流式和批量处理集成
Kafka集群
Kafka天然支持集群
依赖于Zookeeper进行协调
通过brokerId区分不同节点
Kafka副本集：
将日志复制多份
可以为每个Topic设置副本集
可以通过配置设置默认副本集数量
Kafka核心概念
- Broker：Kafka的部署节点
- Leader：用于处理消息的接受和消费等请求
- Follower：主要用于备份消息数据
节点故障
- Kafka与Zookeeper心跳未保持视为节点故障
- follower消息落后leader太多也视为节点故障
- Kafka会对故障节点进行移除
故障处理方式
- 基本不会因为节点故障而丢失数据
- 语义担保很大程度避免数据丢失
- 会对消息进行集群内平衡，减少消息在某些节点热度过高，即不要放一个篮子上
Leader选举
- 并没有采用多数投票来选举leader
- 会动态维护一组Leader数据的副本（ISR）
- 在ISR中选择一个速度比较快的设为Leader
Kafka有一种无奈的情况，ISR中副本全部死机，对于这种情况，会进行unclean leader（脏选举）
1.死等，等到有一个恢复正常
2.在ISR以外的节点使用，确保快速恢复
Leader选举配置建议：.
-
禁用“unclean leader”脏选举
- 手动指定最小ISR