Kafka Exactly Once实现原理：幂等生产者与事务机制深度解析

1. 消息投递语义的演进与Exactly Once的定位

消息中间件领域里，投递语义从来都是绕不开的核心话题。做过几年后端开发的人大概都经历过这样的场景：业务方跑过来问“这条订单消息怎么处理了两次”，或者“为什么库存扣减少了一次”。这类问题的根源，往往就出在消息投递语义的把控上。Kafka作为当前主流的分布式消息系统，它提供的投递语义经历了从At Most Once到At Least Once，再到Exactly Once的演进过程。理解这个演进脉络，是搞清楚Exactly Once实现原理的前提。

1.1 三种投递语义的本质区别

先把这个基础概念理清楚，不然后面聊实现原理容易云里雾里。

At Most Once（至多一次）的意思是消息可能丢失，但绝不会重复。生产者发出消息后不管 broker 有没有收到，发出去就完事。消费者这边先提交 offset 再处理消息，如果处理过程中挂了，offset 已经提交，这条消息就永远不会再被消费到。这种模式适合那些对数据完整性要求不高的场景，比如日志采集，丢几条无所谓。

At Least Once（至少一次）是Kafka默认提供的语义。生产者发送消息后等待 broker 确认，如果没收到确认就重试，直到成功为止。消费者这边先处理消息再提交 offset，如果处理完还没提交 offset 就挂了，重启后会重新消费这条消息。这就保证了消息不丢，但可能重复。绝大多数业务场景用的都是这种模式，配合消费端的幂等处理来达到业务层面的“精确一次”效果。

Exactly Once（精确一次）是最理想的情况：消息既不丢失也不重复，每条消息被处理且仅被处理一次。这个语义在分布式系统中实现起来非常困难，因为它需要跨多个组件协调状态。Kafka从0.11版本开始引入了幂等生产者和事务机制，才真正在系统层面支持了Exactly Once语义。

注意：很多人把“业务幂等”和“Kafka Exactly Once”混为一谈。业务幂等是应用层自己实现的去重逻辑，而Kafka的Exactly Once是消息系统层面提供的保证。两者解决的问题域不同，但可以配合使用。

1.2 为什么Exactly Once这么难实现

分布式系统里有个基本现实：网络不可靠、节点可能故障、时钟不同步。在这三个前提下，要实现“精确一次”的语义，本质上需要解决两个核心问题。

第一个问题是生产端的重复写入。生产者发送消息后，如果 broker 已经写入成功但确认响应在网络中丢失，生产者会认为发送失败并重试。这就导致同一条消息在 broker 端被写入了两次。这个问题在Kafka 0.11之前是无解的，只能靠消费者端做去重。

第二个问题是消费端与提交偏移量的原子性。消费者处理完消息后需要提交 offset，如果处理成功但提交 offset 失败，重启后会重复消费；如果先提交 offset 再处理，处理失败就丢消息。这两个操作必须要么都成功，要么都失败，也就是需要原子性保证。

Kafka的Exactly Once方案就是围绕这两个问题展开的：用幂等生产者解决生产端重复写入，用事务机制解决消费-处理-提交的原子性问题。下面我会逐一拆解这两个机制的工作原理。

1.3 适用场景与代价评估

Exactly Once不是银弹，它带来的性能开销和复杂度提升是实实在在的。开启幂等生产者会增加 broker 端的内存开销，因为需要为每个生产者维护序列号状态。事务机制则更重，需要引入事务协调器、事务日志，并且会增大端到端的延迟。

从实际经验来看，以下场景值得考虑使用Kafka的Exactly Once：

• 金融交易流水同步：每一笔交易记录都不能丢也不能重，对账时差一分钱都是事故。
• 计费系统的事件采集：重复计费比漏计费更让用户反感。
• 流处理中的状态更新：比如Flink与Kafka集成时，EOS保证状态一致性。

而以下场景用At Least Once加业务幂等就够了：

• 日志收集与监控指标上报
• 推荐系统的用户行为埋点
• 缓存失效通知

我个人的判断标准很简单：如果重复消息带来的业务损失大于EOS的性能开销，那就用EOS；否则老老实实做幂等。很多团队一上来就追求EOS，结果发现吞吐量掉了一半，延迟翻了三倍，最后又退回去了。

2. 幂等生产者：生产端去重的核心机制

生产端的重复写入是Exactly Once要解决的第一个问题。Kafka引入幂等生产者（Idempotent Producer）来保证单分区内消息不重复。注意这里的关键词是“单分区内”，跨分区的幂等需要靠事务来保证，后面会细说。

2.1 幂等性的实现思路：序列号与PID

幂等生产者的核心思想非常朴素：给每条消息分配一个单调递增的序列号，broker 端记录每个生产者每个分区的最新序列号，如果收到的消息序列号不连续或者重复，就拒绝写入。

具体来说，生产者初始化时会向 broker 申请一个PID（Producer ID），这个PID在生产者会话期间唯一标识该生产者。同时，生产者会为每个要发送的分区维护一个序列号，从0开始，每发送一条消息递增1。

broker 端会为每个(PID, TopicPartition)组合维护一个状态记录，包含最近接收到的序列号。当收到一条消息时，broker 会检查：

• 如果消息序列号等于期望的下一个序列号（即上次序列号+1），正常写入，更新状态。
• 如果消息序列号小于期望值，说明是重复消息，直接丢弃，但返回成功确认。
• 如果消息序列号大于期望值，说明中间有消息丢失，返回OutOfOrderSequenceException错误。

这个机制的精妙之处在于：重复消息被 broker 静默丢弃，生产者收到的是成功响应。这样生产者不需要关心是否重复，broker 已经帮你处理了。

2.2 序列号的分配与 broker 端状态管理

生产者端的序列号分配逻辑在Sender线程中实现。每个TopicPartition对应一个ProducerBatch，batch 中的每条消息都有一个相对序列号。当 batch 被发送时，生产者会为这个 batch 分配一个基础序列号，batch 内消息的序列号依次递增。

这里有个细节值得注意：序列号是在 batch 级别分配的，不是单条消息级别。一个 batch 可能包含多条消息，它们共享一个基础序列号，broker 端会校验整个 batch 的序列号连续性。这样做的好处是减少了 broker 端的状态维护开销，因为只需要记录每个分区的最后一个序列号。

broker 端的状态管理由ProducerStateManager负责。每个 broker 会为每个活跃的(PID, TopicPartition)维护一个ProducerState对象，记录以下信息：

这些状态会定期写入磁盘（通过ProducerSnapshot），防止 broker 重启后状态丢失。默认情况下，每个 broker 最多缓存max.in.flight.requests.per.connection个未确认的请求，这个值影响序列号乱序的可能性。

2.3 生产者配置与参数调优

要启用幂等生产者，只需要设置一个参数：

enable.idempotence=true

但仅仅设置这个参数还不够，Kafka对相关参数有强制要求。当你开启幂等性后，以下参数会被自动调整或校验：

• acks必须设置为all。因为幂等性需要 broker 确认消息已写入所有同步副本，否则 leader 切换后序列号状态可能不一致。
• retries必须大于0。默认是Integer.MAX_VALUE，确保消息在遇到可重试错误时会重试。
• max.in.flight.requests.per.connection必须小于等于5。这个限制是为了保证序列号在 broker 端不会乱序。如果允许更多未确认请求，网络重试可能导致序列号乱序，broker 会拒绝写入。

实操心得：很多人在开启幂等性后遇到OutOfOrderSequenceException，八成是因为max.in.flight.requests.per.connection设置过大。我一般建议直接保持默认值5，不要动它。如果确实需要提高吞吐量，优先考虑增加分区数或批量大小，而不是增加这个值。

还有一个容易被忽略的参数是transactional.id。如果你只开启幂等性而不使用事务，这个参数不需要设置。但如果你后续要升级到事务模式，就需要设置它。transactional.id的作用是跨生产者会话保持幂等性，后面讲事务时会详细说。

2.4 幂等生产者的边界与局限

幂等生产者解决了单分区单会话内的重复写入问题，但它有几个明确的边界：

第一，只保证单分区内的幂等性。如果一条消息被发送到多个分区，或者生产者重启后PID变化，幂等性就不保证了。跨分区的幂等需要靠事务来实现。

第二，只保证单会话内的幂等性。生产者重启后会申请新的PID，broker 端会把它当作新的生产者，之前的序列号状态不再适用。如果生产者重启前有未确认的消息，重启后重试可能导致重复。

第三，不保证消息不丢失。幂等性只解决重复问题，不解决丢失问题。消息丢失需要靠acks=all和min.insync.replicas来保证。

我在实际项目中遇到过这样的情况：生产者因为网络抖动频繁重连，每次重连都申请新的PID，导致幂等性失效。后来通过调整connections.max.idle.ms和reconnect.backoff.ms参数，减少了不必要的重连，问题才得到缓解。所以幂等性不是开了就万事大吉，还需要关注生产者的连接稳定性。

3. 事务机制：跨分区原子写入的实现

幂等生产者只能保证单分区内的消息不重复，但实际业务中经常需要把多条消息原子性地写入多个分区，或者把消费和生产放在一个事务里。这就需要Kafka的事务机制登场了。

3.1 事务的整体架构与组件协作

Kafka的事务机制涉及几个关键组件，它们各司其职：

• Transaction Coordinator（事务协调器）：每个 broker 都可能充当事务协调器，负责管理事务的生命周期。它维护事务状态，写入事务日志，并协调各分区的事务标记。
• Transaction Log（事务日志）：一个内部主题__transaction_state，持久化存储事务的元数据和状态变更。事务协调器把事务状态写入这个主题，保证故障恢复后能重建事务状态。
• Control Messages（控制消息）：写入用户主题的特殊消息，包括COMMIT和ABORT标记。消费者通过读取这些标记来判断事务的最终状态。
• Producer ID和Epoch：每个事务生产者都有一个PID和epoch，epoch在每次生产者初始化时递增，用于隔离旧会话的残留消息。

事务的完整流程大致是这样的：生产者先向事务协调器注册事务，获取PID和epoch；然后正常发送消息，这些消息会带上PID、epoch和事务ID；发送完成后，生产者向协调器发送提交或回滚请求；协调器先在事务日志中记录最终状态，然后向所有涉及的分区写入控制消息；消费者读取到控制消息后，根据标记决定是否交付事务中的消息。

3.2 事务ID与生产者纪元的作用

transactional.id是事务生产者的核心配置。它和PID的关系需要仔细理解：

• transactional.id是用户指定的，跨生产者会话保持不变。它的作用是让 broker 能够识别“同一个逻辑生产者”，即使物理连接换了、PID变了。
• PID是 broker 分配的，每次生产者初始化时可能不同。它用于标识当前会话。
• Epoch是PID的版本号，每次用同一个transactional.id初始化生产者时，epoch会递增。

当生产者用transactional.id初始化时，事务协调器会检查这个ID是否已经有对应的PID。如果有，就递增epoch，并把这个PID对应的所有未完成事务标记为中止。这个机制叫做僵尸 fencing，目的是防止旧的生产者实例在不知情的情况下继续写入消息。

举个例子：生产者A因为网络分区被隔离，但它以为自己还活着，继续发送消息。同时生产者B用相同的transactional.id启动，epoch递增。当A的消息到达 broker 时，broker 发现epoch比当前的小，就会拒绝这些消息。这样就避免了两个生产者同时写入导致的重复。

注意：transactional.id必须唯一且稳定。如果你用随机值或者每次重启都换一个，事务的跨会话保证就失效了。我一般建议用业务标识来命名，比如order-service-tx-01，这样既唯一又好排查问题。

3.3 事务的完整生命周期拆解

一个典型的事务生命周期包含以下阶段：

阶段一：初始化事务

生产者调用initTransactions()方法，向事务协调器发送InitProducerIdRequest。协调器分配PID和epoch，并记录transactional.id与PID的映射关系。如果这个transactional.id之前有未完成的事务，协调器会先中止它们。

阶段二：开始事务

生产者调用beginTransaction()方法。这个方法在客户端本地标记事务开始，不会向 broker 发送请求。真正的协调发生在第一次发送消息时。

阶段三：发送消息

生产者发送消息时，会在消息头中带上PID、epoch和事务ID。broker 收到消息后，会把这些消息标记为“事务中”状态。这些消息对消费者不可见，直到事务提交。

阶段四：提交或回滚

生产者调用commitTransaction()或abortTransaction()。协调器收到请求后，执行两阶段提交：

1. 先在事务日志中写入PREPARE_COMMIT或PREPARE_ABORT状态。
2. 向所有涉及的分区写入COMMIT或ABORT控制消息。
3. 在事务日志中写入COMPLETE_COMMIT或COMPLETE_ABORT状态。

阶段五：消费者读取

消费者配置isolation.level=read_committed后，会缓存事务中的消息，直到读到控制消息。如果是COMMIT，交付这些消息；如果是ABORT，丢弃这些消息。

3.4 消费端隔离级别的选择

消费者端的isolation.level参数决定了如何处理事务消息：

• read_uncommitted：默认值。消费者会读取所有消息，包括未提交事务中的消息。这个级别下，事务的原子性对消费者不可见。
• read_committed：消费者只读取已提交事务的消息。对于未提交的事务，消息会被缓存，直到事务完成或超时。

这里有个重要的细节：read_committed模式下，消费者仍然会读取到控制消息，但这些消息不会被交付给应用。消费者客户端会自动过滤掉控制消息，应用代码感知不到它们的存在。

还有一个容易踩的坑：read_committed模式下，消费者的position和lastStableOffset可能不一致。lastStableOffset是最后一个已提交事务的 offset，消费者只能读取到这个位置。如果事务长时间不提交，消费者的读取进度会被阻塞。所以事务的超时时间transaction.timeout.ms需要合理设置，默认是60秒，我一般根据业务处理时间调整到30-120秒之间。

4. 端到端Exactly Once的完整链路

前面分别讲了幂等生产者和事务机制，但Exactly Once是一个端到端的概念，需要生产、存储、消费三个环节协同工作。这一章我把整个链路串起来，看看一条消息从生产到消费如何做到精确一次。

4.1 生产端到broker的精确一次

生产端到 broker 的精确一次由幂等生产者保证。核心机制是序列号去重，前面已经详细讲过。这里补充一个关键点：幂等性是和事务绑定使用的。

在事务模式下，生产者的PID和epoch由事务协调器管理。每条消息都带有(PID, epoch, sequenceNumber)三元组。broker 端在写入消息前会校验这个三元组：

• PID必须匹配当前分区的生产者状态。
• epoch必须大于等于当前记录的epoch。如果小于，说明是旧会话的消息，拒绝写入。
• 序列号必须连续。如果不连续，根据情况丢弃或报错。

这个校验发生在 broker 的ProducerStateManager中，是在消息追加到日志之前完成的。校验通过后，消息被写入日志，同时更新生产者状态。

4.2 broker到消费端的精确一次

broker 到消费端的精确一次由事务隔离级别保证。消费者设置isolation.level=read_committed后，只会看到已提交事务的消息。未提交事务的消息会被缓存在客户端，直到收到控制消息。

这里的关键在于控制消息的写入顺序。事务协调器在提交事务时，会向所有涉及的分区写入COMMIT控制消息。这个控制消息的 offset 紧跟在事务消息之后。消费者读取时，先读到事务消息（缓存），再读到COMMIT标记，然后一次性交付所有缓存的消息。

如果事务回滚，协调器写入ABORT标记。消费者读到后，丢弃缓存的消息，继续读取后续消息。整个过程对应用代码透明，应用只需要处理已提交的消息。

4.3 消费-处理-生产的事务闭环

最复杂的场景是“消费-处理-生产”模式：从上游主题消费消息，处理后写入下游主题，同时提交消费 offset。这个模式要做到Exactly Once，需要把消费 offset 的提交也纳入事务。

Kafka提供了sendOffsetsToTransaction()方法来实现这一点。它的工作原理是：把消费 offset 的提交也作为事务的一部分，写入一个内部主题__consumer_offsets。当事务提交时，offset 提交和消息写入一起生效；事务回滚时，两者一起失效。

具体代码结构大致如下：

producer.initTransactions(); while (true) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100)); producer.beginTransaction(); try { for (ConsumerRecord<String, String> record : records) { // 处理消息 String result = process(record.value()); // 写入下游主题 producer.send(new ProducerRecord<>("output-topic", result)); } // 提交消费offset到事务 producer.sendOffsetsToTransaction( currentOffsets(records), consumer.groupMetadata() ); producer.commitTransaction(); } catch (Exception e) { producer.abortTransaction(); // 重置消费者位置 resetToLastCommitted(records); } }

这个模式的关键点在于：offset 提交和消息生产在同一个事务中。如果事务提交成功，offset 和消息都生效；如果失败，两者都回滚，消费者会重新消费这批消息。这样就实现了端到端的精确一次。

实操心得：sendOffsetsToTransaction()的第二个参数在Kafka 2.5之后改成了ConsumerGroupMetadata，不再需要手动传groupId。如果你用的是老版本，升级时要注意这个API变化。另外，这个模式要求消费者的enable.auto.commit=false，否则自动提交会干扰事务。

4.4 性能开销与优化策略

Exactly Once带来的性能开销主要来自三个方面：

第一，事务协调器的额外网络往返。每个事务需要初始化、提交两个阶段，涉及多次RPC调用。事务越多，开销越大。优化策略是合并小事务，把多条消息放在一个事务中提交，减少事务数量。

第二，broker 端的状态维护。每个(PID, TopicPartition)都需要维护序列号状态，内存开销随分区数线性增长。优化策略是控制生产者数量，避免大量短生命周期生产者频繁申请PID。

第三，消费者的缓存开销。read_committed模式下，消费者需要缓存未提交事务的消息。如果事务很大或者长时间不提交，缓存会占用大量内存。优化策略是合理设置事务超时时间，避免事务长时间悬挂。

从实测数据来看，开启Exactly Once后，吞吐量通常会下降20%-50%，延迟增加30%-100%。具体取决于事务大小、分区数量和网络条件。我的建议是：先压测再上线，用真实业务流量测试EOS模式下的性能表现，确认满足SLA后再切换。

5. 常见问题排查与避坑指南

Exactly Once的配置和运维中有不少坑，这一章我整理了一些典型问题和排查思路，都是实际项目中踩过的。

5.1 典型异常与解决方案速查

5.2 事务超时与悬挂事务处理

事务超时是实际运维中最常见的问题。transaction.timeout.ms默认60秒，如果生产者在60秒内没有提交或回滚事务，协调器会自动中止这个事务。

悬挂事务的危害在于：它会阻塞消费者的读取进度。因为read_committed模式下，消费者只能读取到lastStableOffset，而悬挂事务会阻止lastStableOffset前进。如果事务一直不结束，消费者就卡住了。

排查悬挂事务的方法是查看事务日志：

# 查看事务日志主题的内容 kafka-console-consumer.sh \ --bootstrap-server localhost:9092 \ --topic __transaction_state \ --from-beginning \ --property print.key=true

输出中会显示每个事务的状态。如果看到大量Ongoing状态的事务，说明有悬挂事务。解决方法是找到对应的生产者，确认其状态，必要时手动中止事务。

注意：不要随意调大transaction.timeout.ms来“解决”超时问题。超时往往是业务处理逻辑有性能瓶颈的信号，应该先优化处理逻辑，而不是无限延长超时时间。

5.3 消费者卡住不消费的排查思路

消费者在read_committed模式下卡住，通常有以下几个原因：

原因一：有未提交的事务阻塞了lastStableOffset。用kafka-consumer-groups.sh查看消费者的lag，如果lag一直不降，同时lastStableOffset不前进，基本可以确定是这个原因。

原因二：消费者配置了read_committed但生产者没有用事务。这种情况下，普通消息没有事务标记，消费者会一直等待控制消息，导致卡住。解决方法是确认生产端是否开启了事务，如果没有，消费者应该用read_uncommitted。

原因三：事务协调器不可用。如果事务协调器所在的 broker 挂了，事务状态无法更新，消费者会卡住。检查 broker 状态和事务日志主题的副本分布。

排查步骤我一般是这样走的：先看消费者lag，再看lastStableOffset，然后检查事务日志，最后确认生产端配置。这个顺序能覆盖90%的情况。

5.4 跨集群与跨数据中心的事务限制

Kafka的事务机制是集群内的，不支持跨集群的事务。如果你的业务需要跨数据中心写入，事务无法保证原子性。常见的解决方案是：

• 双写+对账：两个集群分别写入，通过离线对账发现不一致并修复。
• 单集群多副本：把副本分布在多个数据中心，用rack感知保证副本分散。
• MirrorMaker + 幂等消费：用镜像工具同步数据，消费端做幂等处理。

我个人的经验是：跨数据中心场景下，不要强求Exactly Once。网络延迟和分区风险会让事务的成功率大幅下降，最终影响可用性。用At Least Once加幂等消费是更务实的选择。

6. 版本演进与生产环境实践建议

Kafka的Exactly Once功能从0.11版本引入，到2.5版本基本成熟，中间经历了不少改进。了解这些演进过程，有助于你在不同版本上做出正确的技术决策。

6.1 关键版本特性对比

从我的实践来看，2.5及以上版本是使用Exactly Once的推荐版本。这个版本的事务API更简洁，性能也更稳定。如果还在用0.11或1.0，建议先升级再考虑EOS。

6.2 生产环境配置清单

以下是我在生产环境中使用Exactly Once的配置清单，可以直接参考：

生产者端：

enable.idempotence=true acks=all retries=Integer.MAX_VALUE max.in.flight.requests.per.connection=5 transactional.id=your-app-tx-01 transaction.timeout.ms=60000

消费者端：

isolation.level=read_committed enable.auto.commit=false

broker端：

transaction.state.log.replication.factor=3 transaction.state.log.min.isr=2 transaction.max.timeout.ms=900000

这些配置的核心逻辑是：保证事务日志的可靠性，同时给事务留出合理的超时窗口。transaction.state.log.replication.factor=3确保事务日志有足够副本，min.isr=2确保至少两个副本同步后才确认写入。

6.3 监控指标与告警设置

Exactly Once的运维需要关注以下指标：

• 事务提交率：kafka.producer:type=producer-metrics,client-id=*下的txn-commit-rate和txn-abort-rate。abort率突然升高说明有异常。
• 事务耗时：txn-init-time-ns-avg和txn-commit-time-ns-avg。耗时增长可能意味着协调器负载过高。
• 悬挂事务数：通过JMX的TransactionCoordinatorMetrics查看OngoingTransactions。这个值持续大于0需要告警。
• 消费者lag：kafka.consumer:type=consumer-fetch-manager-metrics,client-id=*下的records-lag-max。lag持续增长可能是事务阻塞。

我一般会设置这样的告警规则：事务abort率超过5%告警，悬挂事务数超过10告警，消费者lag超过10万告警。这些阈值需要根据业务规模调整，不是固定值。

6.4 从At Least Once迁移到Exactly Once的路径

如果你现在的系统用的是At Least Once，想迁移到Exactly Once，我建议按以下步骤来：

第一步，评估必要性。先算一笔账：当前重复消息带来的业务损失有多大？EOS的性能开销能否接受？如果重复率很低且业务幂等做得好，可能不需要迁移。

第二步，升级版本。确保Kafka版本在2.5以上，broker和客户端都要升级。升级过程中注意兼容性，先升级broker再升级客户端。

第三步，改造生产者。设置transactional.id，把send()调用包裹在事务中。注意处理ProducerFencedException等异常。

第四步，改造消费者。设置isolation.level=read_committed，关闭自动提交。如果涉及消费-生产模式，改用sendOffsetsToTransaction()。

第五步，灰度验证。先在一个非核心业务上试点，观察一周的性能指标和错误率。确认稳定后再逐步推广。

第六步，回滚预案。准备好回滚方案，一旦EOS模式出现严重问题，能快速切回At Least Once。回滚时注意清理悬挂事务，避免影响消费者。

这个迁移过程我做过两次，每次大概需要2-4周。关键是要有耐心，不要一次性全量切换。灰度期间重点观察事务abort率和消费者lag，这两个指标最能反映问题。

6.5 个人经验总结与建议

用了几年Kafka的Exactly Once，我最大的体会是：技术方案要匹配业务需求，不要为了技术而技术。EOS确实能解决消息重复问题，但它带来的复杂度和性能开销也是实实在在的。我见过不少团队为了追求“精确一次”的标签，把系统搞得异常复杂，最后运维成本远超收益。

我的建议是：先做好业务幂等，再考虑EOS。业务幂等是兜底方案，无论消息系统提供什么语义，应用层都应该能处理重复消息。在这个基础上，如果业务对重复零容忍且性能可接受，再开启EOS。这样即使EOS出问题，业务也不会受太大影响。

另外，EOS的运维需要专门的监控和告警。事务状态是分布式的，出问题时排查链路比较长。建议提前建好监控看板，把事务相关的指标都纳入进来。这样出问题时能快速定位，而不是手忙脚乱地翻日志。

最后分享一个小技巧：用transactional.id的命名规范来辅助排查。我一般用{业务名}-{实例编号}的格式，比如payment-tx-01、payment-tx-02。这样在查看事务日志时，一眼就能看出是哪个业务、哪个实例的事务，排查效率能提升不少。