分布式事务中串联全局日志上下文的核心是通过 traceId 统一标识跨服务请求，推荐优先使用 SkyWalking 或 Sleuth+Zipkin 等 APM 框架自动注入 traceId 到 MDC，配合日志框架配置 %X{traceId} 即可输出；若自行实现，需用 TransmittableThreadLocal 保障跨线程传递，并在 HTTP/RPC 调用中透传 X-Trace-ID。

在分布式事务中串联全局日志上下文，核心是让一次业务请求（跨多个服务、数据库、消息队列）产生的所有日志都带上同一个唯一标识（如 traceId），便于问题排查和链路追踪。Java 中最常用、最稳妥的方式是结合 ThreadLocal + MDC + 分布式链路追踪框架 实现，而非手动透传。

用 SkyWalking / Sleuth + Zipkin 自动注入 traceId

推荐优先使用成熟的 APM 框架，它们已内置日志上下文串联能力：

• SkyWalking Agent 可自动为 HTTP、Dubbo、RocketMQ 等主流组件注入 traceId 和 spanId，并写入 SLF4J 的 MDC
• Spring Cloud Sleuth + Zipkin 同样会在日志中自动填充 [traceId, spanId, exportable]，只需配置 logback 或 log4j2 输出 %X{traceId} 即可
• 无需改业务代码，只要引入依赖 + 配置日志 pattern，日志天然带上下文

手动透传时用 MDC 跨线程/跨服务传递

若无法引入 APM，需自行维护上下文，关键点是：MDC 默认不继承子线程，且 HTTP 调用需显式透传

• 入口处（如 Spring MVC Filter）生成 traceId 并放入 MDC：MDC.put("traceId", UUID.randomUUID().toString())
• 异步线程（如 CompletableFuture、线程池）需手动复制 MDC：MDC.getCopyOfContextMap() + 子线程内 MDC.setContextMap(...)
• 调用下游服务时，通过 HTTP Header（如 X-Trace-ID）或 RPC 附件字段透传；下游收到后重新写入 MDC
• 注意：Log4j2 的 AsyncLogger 和某些中间件线程池可能清空 MDC，需检查并适配

分布式事务场景下的特殊处理

Seata、ShardingSphere-Transaction 等框架本身不管理日志上下文，但事务分支执行时可能跨线程或重试，需额外保障

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

立即学习“Java免费学习笔记（深入）”；

• 在 Seata 的全局事务开启处（@GlobalTransactional 方法入口）初始化并绑定 traceId 到 MDC
• 分支事务（如远程服务调用、本地 DB 操作）若由框架内部线程触发（如 Seata 的 RM 异步提交），需确保其执行线程能访问原始 MDC —— 建议封装统一的 TracedRunnable 或使用 TransmittableThreadLocal 替代原生 ThreadLocal
• 避免在 @GlobalTransactional 方法内直接 new Thread()，否则 MDC 丢失；改用包装后的线程池或框架提供的异步扩展点

日志框架配置示例（Logback）

让日志自动打印 traceId，只需在 logback-spring.xml 中配置 pattern：

<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level [%X{traceId}] %logger{36} - %msg%n</pattern>

其中 %X{traceId} 会从 MDC 中取值，为空时不显示，不影响日志格式。