0.11 版本之前保证的语义是：至少一次
至少一次的解释
可以做到消息不丢失--> 可以做到发送成功的消息一定可以被消费到。
不能做到消息不重复。
## 发送成功的消息，表示业务逻辑认为此消息已发送成功，即send方法已执行完成。
丢消息场景
异步发送端：
a：send之后，等待发送的时候down（消息在缓冲区中），导致消息丢失。
b：send时，缓冲区已满，导致消息丢弃。
同步（异步）发送端：
a：有限的重试
服务端Leader down时，因为有与zk的超时timeout，导致在timeout之后才会进行切换， 如果重试次数 * 重试间隔 < zk session timeout + 切换耗时，则消息会丢失。
b：ack ！= -1
ack = 0 的场景，不需服务端确认，发送后，Leader down，导致消息丢失。
ack = 1 的场景，只需要Leader确认，Leader收到消息后，未同步到Replica之前，Leader down，导致消息丢失。
服务端：
a：min.insync.replicas < 2 且 unclean.leader.election.enable = true
min.insync.replicas < 2 的场景下，如果副本均落后Leader，在Leader down时，根据脏选开关，会选择落后的副本作为新的Leader，则落后的数据会丢失。
消费端：
a：自动offset提交
消息处理失败，但是offset也提交了，对业务来说消息丢失。
b：先手动提交offset，后处理消息
先提交offset，后处理消息，但是处理逻辑失败，对业务来说消息丢失。
不丢失数据的方法
发送端：
a：同步发送
b：retries = Long.MAX_VALUE
c：acks = -1
服务端：
a：replication factor = 3
b：min.insync.replicas = 2
c：unclean.leader.election.enable = false
消费端：
a：auto.commit.enable = false
b：仅当消息处理成功之后再提交offset
消息重复的场景
发送端：
a：发送端重试
发送端发送消息后，服务端实际已接收，但是客户端因为网络或其他原因未收到确认响应， 再进行消息重试发送，导致消息重复。
消费端：
a：auto.commit.enable = true
消息处理后，为进行自动offset提交之前，consumer down，恢复后从上个提交点开始消费导致消息处理重复。
消息不重复的方法
发送端 --> 做不到。
消费端 --> auto.commit.enable = false，并且等消息处理完成再提交offset。
0.11之后版本保证的语义是：恰好一次
恰好一次的解释
可以做到消息不丢失 --> 可以做到发送成功的消息一定可以被消费到。
可以做到消息不重复。
发送端做不到消息不重复的解决办法
方法：
给Producer编号，且给每条消息编号，服务端保存Producer编号与此Producer最后一条消息的映射，服务端校验当前收到的消息是否与保存的最后一条消息编号相同，如果相同则拒绝。
配置：
enable.idempotence = true -->
retries = Integer.MAX_VALUE
max.in.flight.requests.per.connection = 1
acks = -1
过程：
a：Producer发送InitProducerIdRequest获取ProducerIdAndEpoch producerId 是Broker从zk分段获取后递增分配的，保证唯一，epoch为事务所用，暂时不提。
b：Producer发送消息（消息中加入ProducerIdAndEpoch，消息序列号（0））。
c：服务端收到消息，内存中维护 ProducerIdAndEpoch与此消息的映射，数据落盘， 同步到副本。
d：Producer发送消息（消息中加入ProducerIdAndEpoch，消息序列号（1））。
e：服务端收到消息，判断内存中的映射是否存在，如不存在，更新映射，数据落盘， 同步到副本，如存在，返回消息重复异常。
判断是否重复的条件：
isFromClient == true &&
batch.producerIdAndEpoch == producerIdAndEpoch &&
batch.baseSequence == firstSeq &&
batch.lastSequence == lastSeq
几个问题：
a：重试的场景中，ProducerIdAndEpoch映射的会不会不是上次重试的消息。
max.in.flight.requests.per.connection代表了同时只能有一条（批）消
息在发送，retries 保证了必须发送成功才会进行下一条的发送，所以不会有映射成其他消息 的情况。
b：有了映射缓存，其他副本没成功复制怎么办 acks = -1 保证了其他副本必须复制成功。
c：服务端启动或新选举为Leader的时候，缓存内容为空怎么判断重复 会先构造缓存内容再提供服务 初始化时加载.snapshot文件，append消息时更新缓存，退出时，写入.snapshot文件。
事务消息
事务消息语义
保证发送消息不重复。
保证多条消息（发往不同服务端）发送的原子性，即同时提交或同时回滚。
保证 “消费-处理-发送”逻辑的原子性，及要么全部成功，要么整体回滚。
整体原理
Producer新增 transactionalId、producerId、epoch标识，可标记事务。
新增transaction coordinator，协调处理事务的开启、提交、终止，记录事务日志 ；
transaction coordinator依附在Broker上，基于Broker提供服务；
记录事务日志是一个内部可根据Key压缩的Topic，可复制的，当 transaction coordinator down，有其他的接管继续事务处理。
服务端只要接收到消息，就写入文件，不管后续是否是提交或者终止。
新增control类型消息，标记事务是提交还是终止（全部消息以transactionalId为标识）。
消费端使用缓存堆积消息，直到看到control类型消息，返回给应用或丢弃。
多条消息发送的原子性
发送消息过程
a：初始化事务
发送FindCoordinatorRequest，查找transaction coordinator。
发送InitProducerIdRequest到transaction coordinator，获取ProducerIdAndEpoch。
transaction coordinator 新增消息 transactionalId --> producerId 到事务日志。
transaction coordinator 恢复或终止此 transactionalId 之前的事务。
b：开启事务
c：生产消息（可多次）
发送AddPartitionsToTxnRequest到transaction coordinator，transaction coordinator增加 BEGIN的事务日志，日志包含此partition 发送消息到实际的Broker，Broker接收消息写入文件并复制到副本
d：提交或终止事务
Producer 发送 EndTxnRequest 到 transaction coordinator transaction coordinator 写入PREPARE_COMMIT或 PREPARE_ABORT到事务日志 transaction coordinator 依次向全部partition发送 COMMIT/ ABORT的control消息 transaction coordinator 写入 COMMIT/ ABORT到事务日志 Broker接收消息写入文件并复制到副本
消费过程（READ_COMMITED）
a：初始化、Rebalance
b：拉消息，如果不包含transactionalId，则返回给应用，如果包含，则放入缓存，直到拉到该transactionalId的control消息，如果该control消息是COMMIT，则相关消息返回应用；如果是ABORT，则删除这些消息
“消费-处理-发送”逻辑的原子性
offset提交：
offset提交除了写zk外，还提供一种写Broker的方式，即新增 consumercoordinator 接收offset 的提交请求，consumercoordinator 将 groupId-offset 写入内部Topic，此Topic可压缩，即旧的 groupId-offset 会被清除，只保留最新的。
处理过程
a：初始化事务
b：开启事务
c：生产消息（可多次）
发送AddPartitionsToTxnRequest到 transaction coordinator，transaction coordinator增加 BEGIN的事务日志，日志包含此partition 发送消息到实际的Broker，Broker接收消息写入文件并复制到副本。
发送 AddOffsetsToTxnRequest 到 transaction coordinator，写入事务日志。
发送 TxnOffsetCommitRequest 到 consumercoordinator，写入文件并复制到副本。
d：提交或终止事务
Producer 发送 EndTxnRequest 到 transaction。
coordinator transaction coordinator 写入PREPARE_COMMIT或 PREPARE_ABORT到事务日志。
transaction coordinator 依次向全部partition发送 COMMIT/ ABORT的control消息。
transaction coordinator 向 consumercoordinator 发送 offset提交的control消息。
transaction coordinator 写入 COMMIT/ ABORT到事务日志。
Broker接收消息写入文件并复制到副本。
消息可见性
offset可见性：
offset提交后，事务提交前，此offset虽然写入文件，但是 consumercoordinator 缓存不更新，直到收到事务提交的control消息才更新缓存，即事务提交前，外部不能查询到此 offset，只能查询到旧的offset。
消息可见性：
a：read_uncommited
所有消息都可被拉取，也可返回给应用处理。
b：read_commited
所有消息都可被拉取，但是只有判断已提交的可返回给应用处理。
失败场景分析
生产端事务开启后，发消息前down：
事务无任何动作，后续会被超时处理掉，不影响事务语义。
生产端事务开启后，发消息后，保存offset前down：
事务会被超时关闭，该消息没有对应的control消息，对外不可见，不影响事务语义。
生产端事务开启后，发消息后，保存offset后，提交事务前down：
事务会被超时关闭，该消息及offset没有对应的control消息，对外不可见，不影响事务语义。
生产端事务提交事务后down：
后续事务动作与客户端无关，由服务端处理，会全部执行完成。
transaction coordinator down：
因为 transaction coordinator 实际为 Broker，Kafka既有机制保证选举新的 coordinator。
因为事务日志是同步的，即最少有三个节点共享事务状态，单个down不影响事务继续。
consumercoordinator down：
事务提交前，offset信息是同步的，但是不生效。
事务提交后，offset信息是同步的，并可对外公开。
broker leader down：
Kafka既有机制保证重新选举Leader，且消息同步。
消费端 down：
read_uncommited的场景，出现消费到未提交事务的消息，且有可能重复。
read_commited的场景，不会消费到未提交事务的消息，其他消费者接管后，从之前位置继续。
最新稳定的消息位置（LSO）
问题：穿插在一批事务消息中间的非事务消息，被消费端消费后，如何提交消费位置
解答：通过LSO机制，即只能消费到最早的全部事务完成的消息位置
事务日志状态
BEGIN
PREPARE_COMMIT
PREPARE_ABORT
COMMIT
ABORT