一、消息队列作用：解耦、削峰、缓冲（生产速度和消费速度不一致）
二、消息队列的两种模式：点对点模式（一对一）、发布订阅模式（一对多 1. 消费者主动拉取消息 2. 队列主动推消息）
三、基础架构：
A、生产者
B、kafka
Broker kafka的一个进程（集群的一个节点）--------------->>>Topic 主题，将数据分类 -------------------------->>>Partion 分区，负载均衡，提高了topic的负载能力-------------------->>>leader，负责业务-------------------------->>>follower，分区的副本，不能提供业务，只是备份
C、消费者
消费者组：
1. 注意：同一个分区只能被同一个消费者组里的一个消费者消费，所有消费者里的消费者数量不能大于订阅主题的分区数量。
2. 消费者组提高了消费能力
D、zookeeper
管理kafka集群的，记录消息消费位置（0.9版本之前是，0.9版本之后就存在本地了）
四、安装kafaka
A、下载并解压到置顶位置
五、修改配置文件
A、server.properties kafka服务端配置
1. broker.id=0 broker的id，必须是唯一的整数
2. delete.topic.enable=true 是否可以删除主题，默认是false
3. log.dirs=/opt/soft/kafka_2.12-2.3.1/data kafka暂存数据目录
4. log.retention.hours=168 数据保留时间（小时）
5. zookeeper.connect=localhost:2181 zookeeper的连接地址
B、常用命令
1. kafka-server-start.sh 启动
2. kafka-server-stop.sh 关闭命令
3. kafka-console-consumer.sh 消费者端
4. kafka-console.producer.sh 生产者端
5. kafka-topics.sh 主题
六、主题的增删改查
1. kafka-topics.sh --list --zookeeper zookeeper节点ip:2181 （查看topic列表）
2. kafka-topics.sh --create --zookeeper zookeeper节点ip:2181 --topic 主题名字 --partitions 分区数 --replication-factor 副本数 （创建主题）
3. kafka-topics.sh --delete --zookeeper zookeeper节点ip:2181 --topic 主题名字 （删除主题）
4. kafka-topics.sh --describe --zookeeper zookeeper节点ip:2181 --topic 主题名字 （主题详情）
七、生产者端
1. 启动生产者端：kafka-console-producer.sh --topic 主题名 --broker-list kafka集群节点ip:9092
八、消费者端
1. 开启消费者端：kafka-console-consumer.sh --topic 主题名 --bootstrap-server kafka集群节点ip:9092 [--from-beginning]是否从头开始消费
九、kafka架构深入
1. topic是逻辑上的概念，partition是物理上的概念，每个partition对应一个log文件
2. 数据可靠性保证
消息发送给partition的leader，所有的follower都同步之后会发送ack
ISR: leader维护了一个动态的in-sync replica set(ISR),意为和leader保持同步的follower集合。当ISR中的follower完成数据同步之后，leader就会给follower发送ack。如果follower长时间没有向leader同步数据，则该follower将被踢出ISR，该时间阈值由replica.time.max.ms参数设置。Leader发生故障之后，就会从ISR中选举新的leader。
3. acks配置
0: producer不等待broker的ack，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当broker故障时可能丢失数据。
1: producer等待broker的ack，partition的leader落盘成功后返回ack，如果在follower同步成功前leader故障，可能丢失数据。
-1(all): producer等待broker的ack,partition的leader和ISR中的follower全部落盘成功后才返回ack。但是如果在follower同步完成之后，broker发送ack之前，leader发生故障，那么会造成重复数据。
4. 故障处理细节
a. follower故障
follower发生故障后会被临时踢出ISR，待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。等待该follower的LEO大于等于该partition的HW时，就可以重新加入ISR了。
b. leader故障
leader故障后从ISR中重新选取一个新的leader，之后为了保证多个副本之间的数据一致性，其余的follower会将各自的log文件高于HW的部分截取掉，然后从新的leader同步数据。
5. exactly-once 精准一次性消费
a. AtLeast Once + 幂等性 = Exactly Once
要启用幂等性，只需要将Producer的参数中enable.idompotence设置为true即可。开启幂等性的producer在初始化的时候会被分配一个pid，发往同一partition的消息会附带sequence number。而broker端会对< pid, partition, sequence number>做缓存，当具有相同主键的消息提交时，broker只会持久化一条。
注意：但是pid重启就会发生变化，同时不同的partition也具有不同的主键，所以幂等性无法保证跨分区跨会话的Exactly Once。
6. 分区分配策略
a. 两种分配策略(RoundRobin和Range)
1) RoundRobin：轮询
多个主题当做一个整体, 所以前提要多个消费者订阅的主题相同
2) Range（默认）
以单个主题来分
b. 当消费者组数量变化的时候会重新分配
7. offset是根据消费者组，分区，主题来确定的
8. 高效读写数据
a. 顺序写磁盘
开辟了一个完整的区间，省去了大量磁头寻址的时间
b. 零拷贝技术
传统: 代码->操作系统->文件->操作系统->代码->操作系统->另一个文件
零拷贝：代码->操作系统->文件->操作系统->另一个文件
9. zookeeper在kafka当中的作用
kafka集群中有一个broker会被选举为controller，负责管理集群broker的上下线、所有topic的分区副本分配和leader选举等工作。controller管理工作都是依赖zookeeper进行的。
10. kafka事务
事务可以跨会话，跨分区做到精准一次性。
a. 生产者事务
为了实现跨分区跨会话 的事务，需要引入一个全局唯一的TransactionID，并将Producer的Pid和transactionID进行绑定。这样当producer重启后就可以通过transactionID获取原来的pid。
为了管理transactionID，kafka引入了一个新的组件transaction coordinator。 producer就是通过和transaction coordinator交互获取transactionID对应的任务状态。transaction coordinator还负责将所有事务写入kafka的一个内部topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。
b. 消费者事务
对于consumer而言，事务的保证相对较弱，尤其无法保证commit的信息被精确消费。这是由于consumer可以通过offset访问任意信息，而且不同的segment file生命周期不同，同一事务的消息可能出现重启后被删除的情况。
11. 消息发送流程
main线程--->send方法(interceptors(拦截器)->serializer(序列化器)->partitioner(分区器))--->RecordAccumulator(记录累加器:待发送数据)--->send线程---->topic