|NO.Z.00071|——————————|BigDataEnd|——|Hadoop&kafka.V56|——|kafka.v56|稳定性|事务相关配置.v03|

一、事务的中止

### --- 事务的中止

~~~     当事务生产者发送业务消息的时候如果发生异常，可以中止该事务。
~~~     如果事务提交超时，事务协调器也会中止当前事务。

~~~     # Producer：向事务协调器发送AbortTransaction(TxId)请求并等待响应。
~~~     (一个没有异常的响应表示事务将会中止)
~~~     Coordinator：向事务控制主题追加PREPARE_ABORT(TxId)消息，然后向生产者发送响应。

~~~     # Coordinator：向事务业务数据的目标主题的每个涉及到的Leader分区Broker
~~~     发送AbortTransaction(TxId, partitions...)请求。
~~~     (收到Leader分区Broker响应后，事务协调器中止动作跟上面的提交类似。)

二、基本事务流程的失败

~~~     # 如果生产者没有中止事务，则协调器将在事务超时后中止事务。
~~~     仅在可能已将请求数据附加并复制到Follower的错误的情况下才需要重做事务。

~~~     # 例如，生产者请求超时将需要重做，而NotLeaderForPartitionException不需要重做。
~~~     生产者发送CommitTransaction(TxId)请求超时或响应中包含异常，生产者使用相同的TxId重试事务。
~~~     此时需要幂等性。

三、主题的压缩

### --- 主题的压缩

~~~     压缩主题在压缩过程中会丢弃具有相同键的早期记录。
~~~     如果这些记录是事务的一部分，这合法吗？这可能有点怪异，但可能不会太有害，
~~~     因为在主题中使用压缩策略的理由是保留关键数据的最新更新。
~~~     如果该应用程序正在（例如）更新某些表，并且事务中的消息对应于不同的键，
~~~     则这种情况可能导致数据库视图不一致

四、事务相关配置：Broker configs

配置项	说明
transactional.id.timeout.ms	在ms中，事务协调器在生产者TransactionalId提前过期之前等待的最长时间，并且没有从该生产者TransactionalId接收到任何事务状态更新。默认是604800000(7天)。这允许每周一次的生产者作业维护它们的id
max.transaction.timeout.ms	事务允许的最大超时如果客户端请求的事务时间超过此时间， broke在InitPidRequest中返回InvalidTransactionTimeout错误。这可以防止客户机超时过大，从而导致用户无法从事务中包含的主题读取内容。默认值为900000(15分钟)。这是消息事务需要发送的时间的保守上限。
transaction.state.log.replication.factor	事务状态topic的副本数量。默认值:3
transaction.state.log.num.partitions	事务状态主题的分区数。默认值:50
transaction.state.log.min.isr	事务状态主题的每个分区ISR最小数量。默认值:2
transaction.state.log.segment.bytes	事务状态主题的segment大小。默认值:104857600字节

五、Producer configs

配置项	说明
enable.idempotence	开启幂等
transaction.timeout.ms	事务超时时间事务协调器在主动中止正在进行的事务之前等待生产者更新事务状态的最长时间。这个配置值将与InitPidRequest一起发送到事务协调器。如果该值大于max.transaction.timeout。在broke中设置ms时，请求将失败，并出现InvalidTransactionTimeout错误。默认是60000。这使得交易不会阻塞下游消费超过一分钟，这在实时应用程序中通常是允许的。
transactional.id	用于事务性交付的TransactionalId。这支持跨多个生产者会话的可靠性语义，因为它允许客户端确保使用相同TransactionalId的事务在启动任何新事务之前已经完成。如果没有提供TransactionalId，则生产者仅限于幂等交付。

六、Consumer configs

配置项	说明
isolation.level	- read_uncommitted:以偏移顺序使用已提交和未提交的消息。 - read_committed:仅以偏移量顺序使用非事务性消息或已提交事务性消息。为了维护偏移排序，这个设置意味着我们必须在使用者中缓冲消息直到看到给定事务中的所有消息。

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