一、为什么要使用异步方式处理LLM流式请求

同步方式的问题

传统的同步处理方式如下：

@GetMappingpublic String chat { // 这里会阻塞10-30秒，等待LLM完整响应 return llmService.chat;}

这种方式存在两个致命问题：

1. 从线程阻塞来看，Tomcat工作线程被长时间占用，无法处理其他请求
2. 从无法流式输出来看，必须等待完整响应才能返回。使用者体验差

异步方式的优势

@GetMappingpublic SseEmitter chatStream { SseEmitter emitter = new SseEmitter;// 异步执行，不阻塞当前线程 CompletableFuture.runAsync -> { callLLMAndStream;},dedicatedExecutor);return emitter;按理说，// 立即返回}

再看主要要点，

• CompletableFuture.runAsync 是"提交即返回"，不等待结果
• 耗时的LLM调用由专用线程池执行，与Web容器线程池隔离
• Controller线程被立即释放。可以继续处理其他请求
• LLM的流式数据通过回调接口实时推送给客户端

二、SseEmitter的主要原理

SseEmitter把一个标准的HTTP请求-响应模式，变成了一条服务器可以随时写入数据的长连接通道。老实说，

工作原理

当Controller返回SseEmitter对象时Spring会：

1. 自动设置响应头 Content-Type: text/event-stream
2. 保持HTTP连接打开。不关闭输出流
3. 后续调用emitter.send时按SSE协议格式化成 data: 内容 写入响应流

生命周期管理

SseEmitter emitter = new SseEmitter;// 超时60秒emitter.send;// 推送数据emitter.complete;说起来，// 正常结束emitter.completeWithError;// 异常结束

三、分布式环境下的取消难点与方法

难点分析

在单机环境下取消流式输出可以直接调用 CompletableFuture.cancel。但在分布式环境中存在以下问题：

• 前端 发起取消请求时可能被负载均衡器路由到不同的节点
• CompletableFuture 对象存在于原节点内存中。其他节点无法直接访问
• 无法跨节点查找和取消正在执行的异步任务

推荐方法的观点是，基于连接状态的被动取消

主要思路的观点是，将"主动查找并取消"转变为"连接断开时被动触发"。取消的本质是客户端不想继续接收数据，那么直接断开连接即可。

实现步骤

1. 客户端主动断开SSE连接

// 取消当前对话，直接关闭连接function cancelStream { if { eventSource.close;按理说，// 触发后端连接断开事件 }}

1. 服务端监听连接断开事件

@GetMappingpublic SseEmitter chatStream { SseEmitter emitter = new SseEmitter;String requestId = UUID.randomUUID.toString;// 注册连接断开回调 emitter.onCompletion -> { // 客户端主动断开或连接正常结束 logger.info;cancelLLMRequest;})，emitter.onError -> { // 连接异常 logger.info;其实，cancelLLMRequest;})，// 异步处理LLM请求 CompletableFuture.runAsync -> { callLLMAndStream;},executor)，return emitter;老实说，}

1. 在数据发送循环中捕获断开信号

private void callLLMAndStream { try { llmClient.streamChat { @Override public void onChunk { try { emitter.send;不过，} catch { // 发送失败说明客户端已断开。停止继续获取数据 logger.info;
throw new RuntimeException;其实，} } @Override public void onComplete { emitter.complete;} })，} catch { emitter.completeWithError;}}

方案优势

• 无需跨节点通信：取消请求就是断开连接，负载均衡器自然会将断开事件路由到正确的节点
• 从无需存储句柄来看，利用现有的TCP连接作为天然的"句柄"
• 实时性高这方面，连接断开时立即触发清理
• 至于实现简单。完全基于SseEmitter已有的回调机制

四、简要示例代码

完整实现

@RestControllerpublic class LLMController { private final ExecutorService llmExecutor = Executors.newFixedThreadPool;按理说，private final Map activeStreams = new ConcurrentHashMap<>;@GetMapping public SseEmitter chatStream { SseEmitter emitter = new SseEmitter;String requestId = UUID.randomUUID.toString;// 监听连接断开 emitter.onCompletion -> { CompletableFuture future = activeStreams.remove;if { future.cancel;} })，CompletableFuture future = CompletableFuture.runAsync -> { try { // 模拟调用LLM流式接口 String chunks = {"Hello"。" ","world","!"}，for { if .isInterrupted) { emitter.complete;return，} emitter.send;Thread.sleep;} emitter.complete;} catch { emitter.completeWithError;}},llmExecutor);activeStreams.put;return emitter;按理说，}}

前端调用

let eventSource = null;function startStream { eventSource = new EventSource;eventSource.onmessage = => { console.log;}，}function cancelStream { if { eventSourceClose;// 触发后端取消 }}

处理LLM流式请求的主要设计思路：

1. 异步处理是必须的：LLM响应慢，必须使用专用线程池异步执行，避免阻塞Web容器线程
2. SseEmitter是关键工具：它将HTTP连接转为可多次写入的数据管道。配合异步机制实现真正的流式输出
3. 分布式取消的最佳策略是"被动触发"：利用SseEmitter的连接断开回调，让客户端断开连接本身成为取消信号，无需复杂的跨节点句柄管理）

这种设计既保障了服务器的并发能力，实现了良好的使用者体验，同时在分布式环境下保持了架构的简洁性和可靠性。