|NO.Z.00070|——————————|BigDataEnd|——|Hadoop&kafka.V55|——|kafka.v55|稳定性|事务相关配置.v02|

一、事务概览

### --- 事务概览

~~~     生产者将表示事务开始/结束/中止状态的事务控制消息发送给
~~~     使用多阶段协议管理事务的高可用==事务协调器==。
~~~     生产者将事务控制记录（开始/结束/中止）发送到事务协调器，
~~~     并将事务的消息直接发送到目标数据分区。

### --- 消费者需要了解事务并缓冲每个待处理的事务，直到它们到达其相应的结束（提交/中止）记录为止。

~~~     ==事务组==
~~~     事务组中的生产者
~~~     事务组的==事务协调器==
~~~     Leader brokers（事务数据所在分区的Broker）
~~~     事务的消费者

二、事务组

### --- 事务组

~~~     事务组用于映射到特定的事务协调器（基于日志分区数字的哈希）。
~~~     该组中的生产者需要配置为该组事务生产者。
~~~     由于来自这些生产者的所有事务都通过此协调器进行，
~~~     因此我们可以在这些事务生产者之间实现严格的有序。

三、生产者ID和事务组状态

### --- 生产者ID和事务组状态

~~~     事务生产者需要两个新参数：==生产者ID==和==生产组==。
~~~     需要将生产者的输入状态与上一个已提交的事务相关联。

~~~     # 这使事务生产者能够重试事务（通过为该事务重新创建输入状态；
~~~     在我们的用例中通常是偏移量的向量）。
~~~     可以使用消费者偏移量管理机制来管理这些状态。
~~~     # 消费者偏移量管理器将每个键（consumergroup-topic-partition ）
~~~     与该分区的最后一个检查点偏移量和元数据相关联。
~~~     在事务生产者中，我们保存消费者的偏移量，该偏移量与事务的提交点关联。
~~~     此偏移提交记录（在__consumer_offsets 主题中）应作为事务的一部分写入。
~~~     即，存储消费组偏移量的__consumer_offsets 主题分区将需要参与事务。

~~~     # 因此，假定生产者在事务中间失败（事务协调器随后到期）；
~~~     当生产者恢复时，它可以发出偏移量获取请求，
~~~     以恢复与最后提交的事务相关联的输入偏移量，并从该点恢复事务处理。
~~~     # 为了支持此功能，我们需要对偏移量管理器和压缩的__consumer_offsets 主题进行一些增强。
~~~     首先，压缩的主题现在还将包含事务控制记录。我们将需要为这些控制记录提出剔除策略。
~~~     其次，偏移量管理器需要具有事务意识；
~~~     特别是，如果组与==待处理的事务==相关联，则偏移量提取请求应返回错误。

四、事务协调器

### --- 事务协调器

~~~     # 事务协调器是__transaction_state 主题特定分区的Leader分区所在的Broker。
~~~     # 它负责初始化、提交以及回滚事务。事务协调器在内存管理如下的状态：
~~~     对应正在处理的事务的第一个消息的HW。事务协调器周期性地将HW写到ZK。
~~~     事务控制日志中存储对应于日志HW的所有正在处理的事务：
~~~     事务消息主题分区的列表。
~~~     事务的超时时间。
~~~     与事务关联的Producer ID。
~~~     # 需要确保无论是什么样的保留策略（日志分区的删除还是压缩），都不能删除包含事务HW的日志分段。

五、事务流程

### --- 初始阶段：(图中步骤A)
~~~     Producer：计算哪个Broker作为事务协调器。
~~~     Producer：向事务协调器发送BeginTransaction(producerId, generation, partitions... )请求，
~~~     当然也可以发送另一个包含事务过期时间的。
~~~     如果生产者需要将消费者状态作为事务的一部分提交事务，
~~~     则需要在BeginTransaction中包含对应的__consumer_offsets 主题分区信息。

~~~     # Broker：生成事务ID
~~~     Coordinator：向事务协调主题追加BEGIN(TxId, producerId, generation, partitions...)消息，
~~~     然后发送响应给生产者。
~~~     Producer：读取响应（包含了事务ID：TxId）
~~~     Coordinator (and followers)：在内存更新当前事务的待确认事务状态和数据分区信息。

### --- 发送阶段：(图中步骤2)

~~~     Producer：发送事务消息给主题Leader分区所在的Broker。
~~~     每个消息需要包含TxId和TxCtl字段。TxCtl仅用于标记事务的最终状态（提交还是中止）。
~~~     生产者请求也封装了生产者ID，但是不追加到日志中。

### --- 结束阶段 (生产者准备提交事务)：(图中步骤3、4、5。)

~~~     Producer：发送OffsetCommitRequest请求提交与事务结束状态关联的输入状态
~~~     （如下一个事务输入从哪儿开始）
~~~     Producer：发送CommitTransaction(TxId, producerId, generation)请求给事务协调器并等待响应。
~~~     (如果响应中没有错误信息，表示将提交事务)
~~~     Coordinator：向事务控制主题追加PREPARE_COMMIT(TxId)请求并向生产者发送响应。
~~~     Coordinator：向事务涉及到的每个Leader分区
~~~     （事务的业务数据的目标主题）的Broker发送一个CommitTransaction(TxId, partitions...)请求。

### --- 事务业务数据的目标主题相关Leader分区Broker：
~~~     如果是非__consumer_offsets 主题的Leader分区：
~~~     一收到CommitTransaction(TxId, partition1, partition2, ...)
~~~     请求就会向对应的分区Broker发送空(null)消息(没有key/value)
~~~     并给该消息设置TxId和TxCtl（设置为COMMITTED）字段。
~~~     Leader分区的Broker给协调器发送响应。

~~~     # 如果是__consumer_offsets 主题的Leader分区：追加消息，
~~~     该消息的key是GLAST-COMMIT ，value就是TxId 的值。
~~~     同时也应该给该消息设置TxId和TxCtl字段。Broker向协调器发送响应。
~~~     Coordinator：向事务控制主题发送COMMITTED(TxId)请求。__transaction_state
~~~     Coordinator (and followers)：尝试更新HW。

Walter Savage Landor:strove with none,for none was worth my strife.Nature I loved and, next to Nature, Art:I warm'd both hands before the fire of life.It sinks, and I am ready to depart

——W.S.Landor