Kafka事务写原理简介

Kafka事务性

当用户使用 Kafka 的事务性时，Kafka 可以做到的保证：

1. 跨会话的幂等性写入：即使中间故障，恢复后依然可以保持幂等性；
2. 跨会话的事务恢复：如果一个应用实例挂了，启动的下一个实例依然可以保证上一个事务完成（commit 或者 abort）；
3. 跨多个 Topic-Partition 的幂等性写入，Kafka 可以保证跨多个 Topic-Partition 的数据要么全部写入成功，要么全部失败，不会出现中间状态。

Kafka 事务性语义提供的保证主要以下三个：

1. Atomic writes across multiple partitions.
2. All messages in a transaction are made visible together, or none are.
3. Consumers must be configured to skip uncommitted messages.

事务性使用实例

Kafka事务使用方法：用户只需要在 Producer 的配置中配置 transactional.id，通过 initTransactions() 初始化事务状态信息，再通过 beginTransaction() 标识一个事务的开始，然后通过 commitTransaction() 或 abortTransaction() 对事务进行 commit 或 abort。

Properties props = new Properties();
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("client.id", "ProducerTranscationnalExample");
props.put("bootstrap.servers", "localhost:9092");
props.put("transactional.id", "test-transactional");
props.put("acks", "all");
KafkaProducer producer = new KafkaProducer(props);
producer.initTransactions();

try {
    String msg = "matt test";
    producer.beginTransaction();
    producer.send(new ProducerRecord(topic, "0", msg.toString()));
    producer.send(new ProducerRecord(topic, "1", msg.toString()));
    producer.send(new ProducerRecord(topic, "2", msg.toString()));
    producer.commitTransaction();
} catch (ProducerFencedException e1) {
    e1.printStackTrace();
    producer.close();
} catch (KafkaException e2) {
    e2.printStackTrace();
    producer.abortTransaction();
}
producer.close();

Kafka事务原理

TransactionCoordinator

TransactionCoordinator 与 GroupCoordinator 有一些相似之处，它主要是处理来自 Transactional Producer 的一些与事务相关的请求，涉及的请求如下表所示：

TransactionCoordinator 对象中还有两个关键的对象：TransactionStateManager用于保存事务的状态。TransactionMarkerChannelManager主要是用于向其他的 Broker 发送 Transaction Marker 数据。

TransactionCoordinator 主要的功能有三个，分别是：

1. 处理事务相关的请求；
2. 维护事务的状态信息；
3. 向其他 Broker 发送 Transaction Marker 数据。

Transaction Log（__transaction_state）

__transaction_state主要用于TransactionCoordinator 故障，对其事务状态信息的恢复。__transaction_state是kafka内部的一个事务Topic，一个事务应该由哪个 TransactionCoordinator 来处理，是根据其 txn.id 的 hash 值与 __transaction_state 的 partition 数取模得到，__transaction_state Partition 默认是50个，假设取模之后的结果是2，那么这个 txn.id 应该由 __transaction_state Partition 2 的 leader 来处理。

__transaction_state 这个 topic 默认是由 Server 端的 transaction.state.log.replication.factor 参数来配置，默认是3，如果当前 leader 故障，需要进行 leader 切换，也就是对应的 TransactionCoordinator 需要迁移到新的 leader 上。

正如 GroupCoordinator 的实现一样，TransactionCoordinator 的恢复也是通过 __transaction_state 中读取之前事务的日志信息，来恢复其状态信息，前提是要求事务日志写入做相应的不丢配置。__transaction_state 与 __consumer_offsets 一样是 compact 类型的 topic。

Transaction Marker

Transaction Marker 也叫做 control messages，它的作用主要是告诉这个事务操作涉及的 Topic-Partition Set 的 leaders 当前的事务操作已经完成，可以执行 commit 或者 abort（Marker 主要的内容就是 commit 或 abort），这个 marker 数据由该事务的 TransactionCoordinator 来发送的。

Transaction Marker 使用过程：

1. 首先 Transactional Producer 需要告诉 TransactionCoordinator 当前事务可以 commit，然后再由 TransactionCoordinator 来向其涉及到的 Topic-Partition 的 leader 发送 Transaction Marker 数据，如果这个目标 Broker 涉及到多个事务操作，是可以共享这个 TCP 连接的；
2. 有了 Transaction Marker 之后，broker在持久化数据时就简单很多，写入的数据跟之前一样，按照条件持久化到硬盘（数据会有一个标识，标识这条或这批数据是不是事务写入的数据），当收到 Transaction Marker 时，把这个 Transaction Marker 数据也直接写入这个 Partition 中，这样在处理 Consumer 消费时，就可以根据 marker 信息做相应的处理。

Server 端事务状态管理

TransactionCoordinator 会维护相应的事务的状态信息（也就是 TxnStatus），对于一个事务，总共有以下几种状态：

其相应有效的状态转移图如下：

正常情况下，对于一个事务而言，其状态状态流程应该是 Empty –> Ongoing –> PrepareCommit –> CompleteCommit –> Empty 或者是 Empty –> Ongoing –> PrepareAbort –> CompleteAbort –> Empty。

Client 端事务状态管理

Client 的事务状态信息主要记录本地事务的状态，本地的状态信息与 Server 端的状态信息并不完全一致。Client 端的事务状态信息主要用于 Client 端的事务状态处理，其主要有以下几种：

1. UNINITIALIZED：Transactional Producer 初始化时的状态，此时还没有事务处理；
2. INITIALIZING：Transactional Producer 调用 initTransactions() 方法初始化事务相关的内容，比如发送 InitProducerIdRequest 请求；
3. READY：对于新建的事务，Transactional Producer 收到来自 TransactionCoordinator 的 InitProducerIdResponse 后，其状态会置为 READY（对于已有的事务而言，是当前事务完成后 Client 的状态会转移为 READY）；
4. IN_TRANSACTION：Transactional Producer 调用 beginTransaction() 方法，开始一个事务，标志着一个事务开始初始化；
5. COMMITTING_TRANSACTION：Transactional Producer 调用 commitTransaction() 方法时，会先更新本地的状态信息；
6. ABORTING_TRANSACTION：Transactional Producer 调用 abortTransaction() 方法时，会先更新本地的状态信息；
7. ABORTABLE_ERROR：在一个事务操作中，如果有数据发送失败，本地状态会转移到这个状态，之后再自动 abort 事务；
8. FATAL_ERROR：转移到这个状态之后，再进行状态转移时，会抛出异常；

client状态如下图：

事务整体流程

这个流程是以 consume-process-produce 场景为例（主要是 kafka streams 的场景），图中红虚框及 4.3a 部分是关于 consumer 的操作，去掉这部分的话，就是只考虑写入情况的场景。这种只考虑写入场景的事务操作目前在业内应用也是非常广泛的，比如 Flink + Kafka 端到端的 Exactly-Once 实现就是这种场景。

1. Finding a TransactionCoordinator

根据事务 txn.id 找到对应的 TransactionCoordinator。Transaction Producer 会向 Broker （随机选择一台 broker，一般选择本地连接最少的这台 broker）发送 FindCoordinatorRequest 请求，获取其 TransactionCoordinator。

2.Getting a PID

Transaction Producer会向 TransactionCoordinator 发送 InitPidRequest 请求获取其分配的 PID，有了 PID，事务写入时可以保证幂等性。TransactionCoordinator 在给事务 Producer 分配 PID 会做一些判断：

1. 如果这个 txn.id 之前没有相应的事务状态（new txn.id），那么会初始化其事务 meta 信息 TransactionMetadata（会给其分配一个 PID，初始的 epoch 为-1），如果有事务状态，获取之前的状态；
2. 校验其 TransactionMetadata 的状态信息：如果前面还有状态转移正在进行，直接返回 CONCURRENT_TRANSACTIONS 异常；如果此时的状态为 PrepareAbort 或 PrepareCommit，返回 CONCURRENT_TRANSACTIONS 异常；如果之前的状态为 CompleteAbort、CompleteCommit 或 Empty，那么先将状态转移为 Empty，然后更新一下 epoch 值；如果之前的状态为 Ongoing，状态会转移成 PrepareEpochFence，然后再 abort 当前的事务，并向 client 返回 CONCURRENT_TRANSACTIONS 异常；如果状态为 Dead 或 PrepareEpochFence，直接抛出相应的 FATAL 异常；

3.Starting a Transaction

前面两步都是 Transaction Producer 调用 initTransactions() 的操作内容。第三步，Producer 可以调用 beginTransaction() 开始一个事务操作。这里只是将本地事务状态转移成 IN_TRANSACTION，并没有与 Server 端进行交互，所以在流程图中没有体现出来（TransactionManager 初始化时，其状态为 UNINITIALIZED，Producer 调用 initializeTransactions() 方法，其状态转移成 INITIALIZING）。

4.Consume-Porcess-Produce Loop

在这个阶段，Transaction Producer 会做相应的处理，主要包括：从 consumer 拉取数据、对数据做相应的处理、通过 Producer 写入到下游系统中（对于只有写入场景，忽略前面那一步即可）：
下面是一个典型的consume-process-produce 场景（start 和 end 中间的部分）：

while (true) {
    ConsumerRecords records = consumer.poll(Long.MAX_VALUE);
    producer.beginTransaction();
    //start
    for (ConsumerRecord record : records){
        producer.send(producerRecord(“outputTopic1”, record));
        producer.send(producerRecord(“outputTopic2”, record));
    }
    producer.sendOffsetsToTransaction(currentOffsets(consumer), group);
    //end
    producer.commitTransaction();
}

4.1. AddPartitionsToTxnRequest

Producer 在调用 send() 方法时，Producer 会将这个对应的 Topic—Partition 添加到 TransactionManager 的记录中。Producer 端的 Sender 线程会将这个信息通过 AddPartitionsToTxnRequest 请求发送给 TransactionCoordinator，也就是图中的 4.1 过程，TransactionCoordinator 会将这个 Topic-Partition 列表更新到 txn.id 对应的 TransactionMetadata 中，并且会持久化到事务日志中，也就是图中的 4.1 a 部分，这里持久化的数据主要是 txn.id 与其涉及到的 Topic-Partition 信息。

4.2. ProduceRequest

一步与正常 Producer 写入基本上一样，就是相应的 Leader 在持久化数据时会在头信息中标识这条数据是不是来自事务 Producer 的写入（主要是数据协议有变动，Server 处理并不需要做额外的处理）。

4.3. AddOffsetsToTxnRequest

Producer 在调用 sendOffsetsToTransaction() 方法时，第一步会首先向 TransactionCoordinator 发送相应的 AddOffsetsToTxnRequest 请求。TransactionCoordinator 在收到这个请求时，处理方法与 4.1 中的一样，把这个 group.id 对应的 __consumer_offsets 的 Partition （与写入涉及的 Topic-Partition 一样）保存到事务对应的 meta 中，之后会持久化相应的事务日志，如图中 4.3a 所示。

4.4. TxnOffsetsCommitRequest

Producer 在收到 TransactionCoordinator 关于 AddOffsetsToTxnRequest 请求的结果后，后再次发送 TxnOffsetsCommitRequest 请求给对应的 GroupCoordinator。

GroupCoordinator 在收到相应的请求后，会将 offset 信息持久化到 consumer offsets log 中（包含对应的 PID 信息），但是不会更新到缓存中，除非这个事务 commit 了，这样的话就可以保证这个 offset 信息对 consumer 是不可见的（没有更新到缓存中的数据是不可见的，通过接口是获取的，这是 GroupCoordinator 本身来保证的）。

5.Committing or Aborting a Transaction

在一个事务操作处理完成之后，Producer 需要调用 commitTransaction() 或者 abortTransaction() 方法来 commit 或者 abort 这个事务操作。

5.1. EndTxnRequest

无论是 Commit 还是 Abort，对于 Producer 而言，都是向 TransactionCoordinator 发送 EndTxnRequest 请求，这个请求的内容里会标识是 commit 操作还是 abort 操作。它们最终都是调用了 TransactionManager 的 beginCompletingTransaction() 方法，这个方法会向其 待发送请求列表 中添加 EndTxnRequest 请求。

TransactionCoordinator 在收到 EndTxnRequest 请求后，会做以下处理：

1. 更新事务的 meta 信息，状态转移成 PREPARE_COMMIT 或 PREPARE_ABORT，并将事务状态信息持久化到事务日志中；
2. 根据事务 meta 信息，向其涉及到的所有 Topic-Partition 的 leader 发送 Transaction Marker 信息（也就是 WriteTxnMarkerRquest 请求，见下面的 5.2 分析）；
3. 最后将事务状态更新为 COMMIT 或者 ABORT，并将事务的 meta 持久化到事务日志中，也就是 5.3 步骤。

5.2. WriteTxnMarkerRquest

WriteTxnMarkerRquest 是 TransactionCoordinator 收到 Producer 的 EndTxnRequest 请求后向其他 Broker 发送的请求，主要是告诉它们事务已经完成。不论是普通的 Topic-Partition 还是 __consumer_offsets，在收到这个请求后，都会把事务结果（Transaction Marker ）持久化到对应的日志文件中，这样下游 Consumer 在消费这个数据时，就知道这个事务是 commit 还是 abort。

5.3. Writing the Final Commit or Abort Message

当这个事务涉及到所有 Topic-Partition 都已经把这个 marker 信息持久化到日志文件之后，TransactionCoordinator 会将这个事务的状态置为 COMMIT 或 ABORT，并持久化到事务日志文件中，到这里，这个事务操作就算真正完成了，TransactionCoordinator 缓存的很多关于这个事务的数据可以被清除了。

事务中间故障恢复

实际生产环境中，事务流程的任何一个地方都有可能出现失败：

1. Producer 在发送 beginTransaction() 时，如果出现 timeout 或者错误：Producer 只需要重试即可；
2. Producer 在发送数据时出现错误：Producer 应该 abort 这个事务，如果 Produce 没有 abort（比如设置了重试无限次，并且 batch 超时设置得非常大），TransactionCoordinator 将会在这个事务超时之后 abort 这个事务操作；
3. Producer 发送 commitTransaction() 时出现 timeout 或者错误：Producer 应该重试这个请求；
4. Coordinator Failure：如果 Transaction Coordinator 发生切换（事务 topic leader 切换），Coordinator 可以从日志中恢复。如果发送事务有处于 PREPARE_COMMIT 或 PREPARE_ABORT 状态，那么直接执行 commit 或者 abort 操作，如果是一个正在进行的事务，Coordinator 的失败并不需要 abort 事务，producer 只需要向新的 Coordinator 发送请求即可。

Fencing（解决脑裂问题）

Fencing 机制解决的主要是脑裂问题。简单来说就是，本来系统这个组件在某个时刻应该只有一个处于 active 状态的，但是在实际生产环境中，特别是切换期间，可能会同时出现两个组件处于 active 状态，这就是脑裂问题。在 Kafka 的事务场景下，用到 Fencing 机制有两个地方：

1. TransactionCoordinator Fencing；
2. Producer Fencing；

TransactionCoordinator Fencing

TransactionCoordinator 在遇到上 long FGC 时，可能会导致 脑裂 问题，FGC 时会 stop-the-world，这时候可能会与 zk 连接超时导致临时节点消失进而触发 leader 选举，如果 __transaction_state 发生了 leader 选举，TransactionCoordinator 就会切换，如果此时旧的 TransactionCoordinator FGC 完成，在还没来得及同步到最细 meta 之前，会有一个短暂的时刻，对于一个 txn.id 而言就是这个时刻可能出现了两个 TransactionCoordinator。

通过 CoordinatorEpoch 来判断，每个 TransactionCoordinator 都有其 CoordinatorEpoch 值，这个值就是对应 __transaction_state Partition 的 Epoch 值（每当 leader 切换一次，该值就会自增1）。有了 CoordinatorEpoch 之后，其他 Server 在收到请求时做相应的判断，如果发现 CoordinatorEpoch 值比缓存的最新的值小，那么 Fencing 就生效，拒绝这个请求，也就是 TransactionCoordinator 发送 WriteTxnMarkerRequest 时可能会触发这一机制。

Producer Fencing

Producer Fencing 与前面的类似，如果对于相同 PID 和 txn.id 的 Producer，Server 端会记录最新的 Epoch 值，拒绝来自 zombie Producer （Epoch 值小的 Producer）的请求。

当两个具有相同txn.id的producer启动时，Producer 1首先会向 TransactionCoordinator 发送 InitPIDRequest 请求，此时TransactionCoordinator 已经没有这个 txn.id 对应的 meta，所以会返回给其新的PID，epoch设置为-1。当Producer 2 在启动时，因为TransactionCoordinator 已经有了这个 txn.id 对应的 meta，会返回之前分配的 PID，并把 Epoch 自增 1（此处也有可能会报异常）。

这样 Producer 2 就被认为是最新的 Producer，而 Producer 1 就会被认为是 zombie Producer，因此，TransactionCoordinator 在处理 Producer 1 的事务请求时，会返回相应的异常信息。

Consumer 消费事务数据

事务场景下，Consumer 的消费策略，Consumer 有一个 isolation.level 配置，这个是配置对于事务性数据的消费策略，有以下两种可选配置：

1. read_committed: only consume non-­transactional messages or transactional messages that are already committed, in offset ordering.
2. read_uncommitted: consume all available messages in offset ordering. This is the default value.

简单来说就是，read_committed 只会读取 commit 的数据，而 abort 的数据不会向 consumer 显现，对于 read_uncommitted 这种模式，consumer 可以读取到所有数据（control msg 会过滤掉），这种模式与普通的消费机制基本没有区别，就是做了一个 check，过滤掉 control msg（也就是 marker 数据），这部分的难点在于 read_committed 机制的实现。

Last Stable Offset（LSO）

在事务机制的实现中，Kafka 又设置了一个新的 offset 概念，那就是 Last Stable Offset.

The LSO is defined as the latest offset such that the status of all transactional messages at lower offsets have been determined (i.e. committed or aborted).

对于一个 Partition 而言，offset 小于 LSO 的数据，全都是已经确定的数据，这个主要是对于事务操作而言，在这个 offset 之前的事务操作都是已经完成的事务（已经 commit 或 abort），如果这个 Partition 没有涉及到事务数据，那么 LSO 就是其 HW（水位）。

Server 处理 read_committed 类型的 Fetch 请求

如果 Consumer 的消费策略设置的是 read_committed，其在向 Server 发送 Fetch 请求时，Server 端只会返回 LSO 之前的数据，在 LSO 之后的数据不会返回。

但是这种机制存在一个问题：如果有一个 long transaction，比如其 first offset 是 1000，另外有几个已经完成的小事务操作，比如：txn1（offset：1100_{1200）、txn2（offset：1400}1500），假设此时的 LSO 是 1000，也就是说这个 long transaction 还没有完成，那么已经完成的 txn1、txn2 也会对 consumer 不可见（假设都是 commit 操作），此时受 long transaction 的影响可能会导致数据有延迟。

Consumer 如何过滤 abort 的事务数据

Broker 会追踪每个 Partition 涉及到的 abort transactions，Partition 的每个 log segment 都会有一个单独只写的文件（append-only file）来存储 abort transaction 信息，因为 abort transaction 并不是很多，所以这个开销是可以可以接受的，之所以要持久化到磁盘，主要是为了故障后快速恢复，要不然 Broker 需要把这个 Partition 的所有数据都读一遍，才能直到哪些事务是 abort 的。如果这个 Partition 没有事务操作，就不会生成这个文件）。这个持久化的文件是以 .txnindex 做后缀。

有了这个设计，Consumer 在拉取数据时，Broker 会把这批数据涉及到的所有 abort transaction 信息都返回给 Consumer，Server 端会根据拉取的 offset 范围与 abort transaction 的 offset 做对比。Consumer 在拿到这些数据之后，会进行相应的过滤，Server 端返回的 abort transaction 列表保存在 abortedTransactions 集合中：

1. 如果这个数据是 control msg（也即是 marker 数据），是 ABORT 的话，那么与这个事务相关的 PID 信息从 abortedProducerIds 集合删掉，是 COMMIT 的话，就忽略（每个这个 PID 对应的 marker 数据收到之后，就从 abortedProducerIds 中清除这个 PID 信息）；
2. 如果这个数据是正常的数据，把它的 PID 和 offset 信息与 abortedTransactions 队列（有序队列，头部 transaction 的 first offset 最小）第一个 transaction 做比较，如果 PID 相同，并且 offset 大于等于这个 transaction 的 first offset，就将这个 PID 信息添加到 abortedProducerIds 集合中，同时从 abortedTransactions 队列中删除这个 transaction，最后再丢掉这个 batch（它是 abort transaction 的数据）；
3. 检查这个 batch 的 PID 是否在 abortedProducerIds 集合中，在的话，就丢弃，不在的话就返回上层应用。

其严重依赖了 Kafka 提供的下面两种保证：

1. Consumer 拉取到的数据，在处理时，其 offset 是严格有序的；
2. 同一个 txn.id（PID 相同）在某一个时刻最多只能有一个事务正在进行；

事务超时

Producer 在开始一个事务操作时，可以设置其事务超时时间（参数是 transaction.timeout.ms，默认60s），而且 Server 端还有一个最大可允许的事务操作超时时间（参数是 transaction.timeout.ms，默认是15min），Producer 设置超时时间不能超过 Server，否则的话会抛出异常。

txn.id过期

对于 txn.id，我们知道 TransactionCoordinator 会缓存 txn.id 的相关信息，如果没有超时机制，这个 meta 大小是无法预估的，Server 端提供了一个 transaction.id.expiration.ms 参数来配置这个超时时间（默认是7天），如果超过这个时间没有任何事务相关的请求发送过来，那么 TransactionCoordinator 将会使这个 txn.id 过期。