次元画室Java八股文实践题设计一个高并发的AI绘画任务队列最近在带团队里的新人发现他们背了不少Java八股文但一遇到真实的生产场景就有点懵。正好我们内部有个叫“次元画室”的AI绘画小项目我就想能不能用它来设计一道实践题把那些面试常问的线程池、消息队列、缓存这些知识点串起来让大家真正动手练练。这个场景很典型用户上传一张草图或者一段文字描述后台调用AI模型生成一张画。这个过程耗时比较长从几秒到几十秒不等而且用户可能同时提交很多请求。你不可能让用户在前端干等着浏览器连接超时了怎么办服务器资源被占满了怎么办这就是一个典型的需要“异步任务队列”来解决的高并发场景。今天我们就来聊聊怎么用Java后端那些经典技术为“次元画室”设计一个扛得住压力、体验又好的绘画任务队列系统。这不仅是道很好的面试题更是一个能写进简历的真实项目经验。1. 场景拆解我们到底要解决什么问题在动手写代码之前得先想明白业务到底需要什么。用户点一下“生成”按钮背后发生了什么首先生成一张AI绘画不是瞬间完成的。它可能需要调用一个远程的AI服务接口或者在本机跑一个深度学习模型。这个过程短则三五秒长则半分钟。如果让用户的HTTP请求一直等着这个结果连接很可能超时用户体验极差。其次AI模型本身很吃资源比如GPU。我们服务器的计算能力是有限的不可能同时处理无数个绘画请求。如果一下子涌进来100个请求全丢给模型去跑服务器可能直接就卡死了。所以我们的核心目标就两个快速响应用户提交请求后后台立刻返回一个“任务已接受正在处理”的回应让用户先去干别的。平稳处理把收到的绘画任务排好队让服务器按照自己的能力一个个或者一小批一小批地去执行避免把系统压垮。这就像去网红餐厅吃饭服务员不会让你站在灶台旁边等菜而是给你一个号码牌让你先去坐着等菜好了再叫你。我们的任务队列系统就是这个发号码牌和叫号的服务员。2. 系统设计核心组件如何选型与协作明确了问题我们就可以开始搭架子了。一个高并发的任务队列系统通常由几个核心部分组成我画了一个简单的示意图帮你理解用户请求 - Web服务器 - 任务队列 - 任务处理器 - 结果存储 - 用户轮询/回调我们来分解一下每个环节的技术选型和思考。2.1 任务接收与异步响应当用户从前端提交一个绘画请求比如包含了描述文本和风格参数时我们的Web服务比如用Spring Boot写的会接收到这个POST请求。这里的关键是不能在这个HTTP请求线程里直接去调用耗时的AI服务。我们应该做这几件事生成唯一任务ID比如用一个UUID这个ID将贯穿整个任务生命周期。快速校验参数检查参数是否合法但先不进行真正的业务处理。将任务信息暂存把任务ID、用户ID、绘画参数、提交时间等存到一个地方比如数据库状态标记为“待处理”。发送任务到队列将任务ID或任务消息体发送到我们后面要说的消息队列里。立即返回响应告诉前端“任务ID: xxx已提交成功请稍后查询结果”。响应时间应该控制在几十毫秒内。这样用户的浏览器很快就得到了反馈连接可以关闭了。剩下的脏活累活交给后台系统慢慢处理。2.2 任务缓冲与削峰填谷消息队列为什么需要消息队列比如RabbitMQ、Kafka它在这里扮演了“缓冲区”和“调度中心”的角色。想象一下突然有一个大V转发推荐了“次元画室”瞬间涌进来一万个绘画请求。如果没有队列这一万个请求会直接冲击我们的任务处理服务可能瞬间创建上万个线程导致服务崩溃。消息队列的好处是削峰流量高峰时请求堆积在队列里处理服务按照自己的能力慢慢消费。解耦任务提交服务生产者和任务处理服务消费者完全独立互不影响。生产者只需要确保消息发出去了不用关心谁处理、什么时候处理。可靠像RabbitMQ这样的队列消息可以持久化到磁盘即使服务重启任务也不会丢失。在这个场景里我们可以创建一个叫ai-painting-tasks的队列。任务提交服务就是生产者不断往里面扔消息。任务处理服务就是消费者从队列里取消息出来执行。2.3 任务处理线程池的精打细算从队列里取出任务后具体谁去执行AI绘画这个耗时操作这里就要用到Java并发包里的明星——线程池。我们不能来一个任务就创建一个新线程new Thread()线程的创建和销毁成本很高。线程池可以复用一组预先创建好的线程。对于AI绘画任务我们可能需要一个固定大小的线程池。为什么因为同时运行的绘画任务数往往受限于我们服务器的GPU数量或AI服务的并发限制。比如我们只有2张GPU卡可能最多只能同时跑4个任务。那么线程池的核心线程数就可以设为4。import java.util.concurrent.*; // 创建一个固定大小为4的线程池用于执行AI绘画任务 ExecutorService paintingExecutor Executors.newFixedThreadPool(4); // 队列用于存放任务描述和参数 BlockingQueueTask taskQueue new LinkedBlockingQueue(); // 消费者线程从消息队列获取任务后提交给线程池 public void onTaskMessageReceived(TaskMessage message) { PaintingTask task convertToPaintingTask(message); paintingExecutor.submit(() - { try { processPaintingTask(task); // 这里包含调用AI模型的耗时操作 } catch (Exception e) { // 处理异常更新任务状态为失败 } }); }线程池会管理这4个线程的生命周期。当4个线程都在忙时新来的任务会在内部队列里等待。这样无论外部流量多大同时执行的任务数都被限制在4个保护了底层资源。2.4 结果缓存与状态查询任务在后台处理用户怎么知道进度和结果呢有两种常见方式方式一主动轮询前端每隔几秒比如5秒发一次请求询问任务ID对应的状态处理中、成功、失败和结果成功时的图片URL。这个查询接口必须非常快所以结果一定要缓存。我们可以用Redis来存任务结果。当任务处理成功后将图片的存储地址比如OSS的URL和任务信息存入Redis并设置一个过期时间比如1天。用户查询时直接从Redis获取速度极快。// 任务处理成功后 String taskId task.getId(); String imageUrl https://oss.example.com/paintings/ taskId .png; MapString, String result new HashMap(); result.put(status, SUCCESS); result.put(imageUrl, imageUrl); result.put(finishedAt, System.currentTimeMillis()); // 存入Redis过期时间1小时 redisTemplate.opsForValue().set(task:result: taskId, result, 1, TimeUnit.HOURS);方式二异步回调更高级一点的做法是用户提交任务时提供一个回调地址Callback URL。当任务处理完成后我们的服务主动向这个地址发送一个HTTP POST请求通知用户任务完成并把结果带过去。这需要用户侧也有一个能接收请求的服务更适合系统间的集成。2.5 失败处理与重试机制事情不会总是一帆风顺。网络可能会抖动AI服务可能暂时不可用图片上传可能会失败。我们必须考虑失败的情况。一个健壮的系统应该有重试机制。比如调用AI服务失败时如果不是参数错误这类“注定失败”的问题可以尝试重试几次。但要注意指数退避不要失败后立刻重试等1秒、2秒、4秒……逐渐增加等待时间避免对故障服务造成连续冲击。最大重试次数比如重试3次后还是失败就标记任务为最终失败并记录错误原因。死信队列对于反复失败的任务可以将其转移到另一个特殊的队列死信队列中方便后续人工排查或批量处理。3. 核心代码实践从理论到代码说了这么多我们来看一些关键环节的代码片段感受一下如何实现。这里以Spring Boot RabbitMQ Redis为例。3.1 任务提交接口这是用户最先接触的入口。RestController RequestMapping(/api/paint) public class PaintingController { Autowired private TaskQueueService taskQueueService; Autowired private TaskStatusService taskStatusService; PostMapping(/submit) public ApiResponseTaskSubmitResponse submitPaintingTask(RequestBody PaintingRequest request) { // 1. 参数基础校验 if (StringUtils.isBlank(request.getDescription())) { return ApiResponse.error(描述不能为空); } // 2. 生成唯一任务ID String taskId UUID.randomUUID().toString(); // 3. 构造任务对象初始状态为 PENDING PaintingTask task new PaintingTask(); task.setTaskId(taskId); task.setUserId(request.getUserId()); // 从token解析 task.setDescription(request.getDescription()); task.setStyle(request.getStyle()); task.setStatus(TaskStatus.PENDING); task.setCreateTime(new Date()); // 4. 将任务信息持久化到数据库可选用于管理后台查看 taskStatusService.saveTask(task); // 5. 发送任务到消息队列 taskQueueService.sendPaintingTask(task); // 6. 立即返回响应 TaskSubmitResponse response new TaskSubmitResponse(); response.setTaskId(taskId); response.setMessage(绘画任务已提交请使用此taskId查询进度); response.setEstimateWaitTime(30); // 预估等待30秒可根据队列长度动态计算 return ApiResponse.success(response); } }3.2 消息队列生产者负责把任务丢进队列。Service public class RabbitMQTaskQueueService implements TaskQueueService { Autowired private RabbitTemplate rabbitTemplate; Override public void sendPaintingTask(PaintingTask task) { // 将任务对象转换为消息 PaintingTaskMessage message convertToMessage(task); // 发送到指定的交换机Exchange和路由键RoutingKey最终进入ai.painting.task队列 rabbitTemplate.convertAndSend(painting.exchange, painting.task, message); log.info(任务已发送到队列taskId: {}, task.getTaskId()); } }3.3 消息队列消费者与任务处理这是最核心的部分从队列取任务并执行。Component public class PaintingTaskConsumer { Autowired private PaintingService paintingService; // 实际调用AI绘画服务的类 Autowired private TaskStatusService taskStatusService; Autowired private RedisTemplateString, Object redisTemplate; // 使用一个固定大小的线程池假设最大并发为4 private final ExecutorService taskExecutor Executors.newFixedThreadPool(4); RabbitListener(queues ai.painting.task) public void handlePaintingTask(PaintingTaskMessage message) { log.info(接收到绘画任务: {}, message.getTaskId()); // 更新任务状态为处理中 taskStatusService.updateStatus(message.getTaskId(), TaskStatus.PROCESSING); // 提交到线程池异步执行 taskExecutor.submit(() - { try { // 1. 调用AI绘画服务这里是耗时操作 byte[] imageData paintingService.generateImage( message.getDescription(), message.getStyle() ); // 2. 将生成的图片上传到对象存储如阿里云OSS String imageUrl uploadToOSS(imageData, message.getTaskId()); // 3. 将结果存入Redis缓存 cacheTaskResult(message.getTaskId(), imageUrl); // 4. 更新数据库任务状态为成功 taskStatusService.updateStatus(message.getTaskId(), TaskStatus.SUCCESS, imageUrl); log.info(任务处理成功: {}, message.getTaskId()); // 5. 可选发送任务完成通知如WebSocket推送或回调 // notificationService.notifyUser(message.getUserId(), message.getTaskId()); } catch (Exception e) { log.error(处理绘画任务失败, taskId: message.getTaskId(), e); // 更新任务状态为失败 taskStatusService.updateStatus(message.getTaskId(), TaskStatus.FAILED, e.getMessage()); // 可以考虑将失败任务放入重试队列或死信队列 } }); } private void cacheTaskResult(String taskId, String imageUrl) { MapString, String result new HashMap(); result.put(status, SUCCESS); result.put(imageUrl, imageUrl); result.put(finishedAt, String.valueOf(System.currentTimeMillis())); redisTemplate.opsForValue().set(task:result: taskId, result, 1, TimeUnit.HOURS); } }3.4 任务状态查询接口用户轮询的入口要求响应极快。RestController RequestMapping(/api/task) public class TaskStatusController { Autowired private RedisTemplateString, Object redisTemplate; Autowired private TaskStatusService taskStatusService; GetMapping(/status/{taskId}) public ApiResponseTaskStatusResponse getTaskStatus(PathVariable String taskId) { // 1. 首先尝试从Redis缓存获取最快 Object cachedResult redisTemplate.opsForValue().get(task:result: taskId); if (cachedResult ! null) { return ApiResponse.success(convertToResponse(cachedResult)); } // 2. 缓存没有则从数据库查询作为兜底或处理中状态 PaintingTask task taskStatusService.getTask(taskId); if (task null) { return ApiResponse.error(任务不存在); } TaskStatusResponse response new TaskStatusResponse(); response.setTaskId(taskId); response.setStatus(task.getStatus().name()); response.setProgress(task.getProgress()); // 如果有进度字段的话 response.setImageUrl(task.getResultUrl()); return ApiResponse.success(response); } }4. 项目实战中的进阶思考把上面这些代码跑起来一个基本可用的任务队列系统就有了。但如果你想在面试中脱颖而出或者在实际项目中做得更扎实下面这些进阶思考能帮你加分。如何估算和设置线程池大小这没有固定答案。假设我们用的AI服务单任务平均耗时10秒我们希望系统吞吐量是每分钟处理60个任务。那么理想情况下我们需要60 tasks/min / (60 sec/min / 10 sec/task) 10个并发线程。但还要考虑服务器CPU核心数、内存、以及AI服务自身的并发限制。通常需要压测来找到最佳值。队列积压了怎么办如果任务生产速度持续大于消费速度队列会越来越长。除了扩容消费者加机器、加线程我们还可以动态调整线程池大小根据队列长度适当增加核心线程数但要在资源允许范围内。任务优先级给VIP用户或加急任务设置更高的优先级让他们插队。优雅降级当队列超过一定长度时拒绝新的普通任务或者返回一个更长的预估等待时间引导用户稍后再试。如何保证任务不丢失这是一个分布式系统常见的问题。我们需要在几个环节保证消息队列持久化确保RabbitMQ的消息和队列本身都设置了持久化。消费者手动确认在RabbitMQ中等任务真正处理成功后再向队列发送ACK确认。如果处理失败或消费者宕机队列会把消息重新投递给其他消费者。结果缓存和数据库的双写就像我们代码里做的结果既写Redis也写数据库。即使Redis挂了用户还能从数据库查到最终状态虽然慢点。这个设计能应对多大规模这个架构是经典的生产者-消费者模式扩展性很好。当用户量变大时横向扩展消费者可以部署多个任务处理服务实例它们都从同一个消息队列消费任务天然负载均衡。队列分区如果单个队列成为瓶颈可以考虑使用像Kafka这样的消息系统将任务按某种规则比如用户ID哈希分发到多个分区Partition由不同的消费者组处理。引入任务调度器对于更复杂的场景比如有不同类型的任务绘画、超分、风格迁移且资源需求不同可以引入更高级的任务调度系统如Apache DolphinScheduler、Airflow来管理。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。