Spring Webflux + Sleuth Zipkin 相同Trace ID不同Span ID能否证明存在重复请求？

问题1：相同Trace ID、不同Span ID是否可以作为存在至少两次请求的实锤证据？ #

不能直接作为100%实锤，但属于极强的指向性证据：

• 正常场景下，单次HTTP请求进入Spring Webflux服务时，Sleuth会生成唯一的服务端根Span，你贴的正常日志中Trace ID和Span ID完全一致就是典型的单次请求表现。
• 出现同Trace、不同Span的两次Controller入口日志，绝大多数情况是有两次携带相同Trace ID的请求进入了服务端。如果Trace ID是由客户端初始生成并通过Sleuth约定的透传头传递的，那么中间网关、代理层的重试请求都会携带相同的Trace ID，这种场景下客户端只会记录一次出站请求，完全符合你遇到的现象。
• 仅存的极小概率例外是Sleuth配置异常、Span生成逻辑被自定义改造出错，导致单次请求内生成了多个根Span并在MDC中生效，这种场景可以通过对比正常请求的Span规则快速排除。

问题2：日志中不同的[or-http-epoll-2]和[or-http-epoll-3]线程信息是否可以辅助证明重复请求？ #

可以作为非常有效的辅助证据：

• or-http-epoll-*是Netty服务端处理HTTP请求的IO工作线程，单次请求的Controller入口逻辑只会在同一个IO线程上触发执行，不会跨线程打印入口日志。
• 两次日志落在不同的IO线程，说明这是两个独立的请求处理任务，基本排除了单次请求内日志重复打印的可能性。

问题3：仅凭借现有信息能否确定存在重复请求？ #

无法100%确定，但重复请求的概率超过99%：

• 目前的证据已经可以排除绝大多数单次请求的可能性，仅剩极其罕见的边缘场景，比如JVM日志输出故障、Sleuth上下文传递BUG导致同请求重复打日志且Span ID异常。
• 如果需要完全实锤，可以补充两个排查动作：在服务端添加请求过滤器，记录每个请求的TCP源端口、请求唯一标识等信息；或者抓取服务端的TCP报文，确认是否有两次独立的HTTP请求报文进入。

内容的提问来源于stack exchange，提问作者PatPanda