1. 项目背景与核心挑战

在站群系统的实际运营中，内容编辑器的多图并发上传是个高频刚需场景。我们团队最近在重构一个日均处理10万+文章的站群平台时，就遇到了CKEditor批量上传图片到.NET后端的性能瓶颈。当编辑人员一次性上传20张以上的高清配图时，服务器频繁出现请求阻塞、内存溢出甚至直接宕机的情况。

经过抓包分析发现，CKEditor默认的图片上传机制是典型的"队列式串行上传"——每张图片独立发起一个HTTP POST请求，必须等待前一张上传完成才会继续下一张。这种设计在传统单站场景下问题不大，但在站群环境中，当50个编辑同时操作时，IIS应用池的可用线程数会被迅速耗尽。

2. 技术方案选型与对比

2.1 传统方案的问题分析

先来看原始方案的实现逻辑（示例代码）：

[HttpPost] public ActionResult UploadImage(HttpPostedFileBase upload) { if (upload.ContentLength > 0) { var fileName = Path.GetFileName(upload.FileName); var filePath = Server.MapPath("~/Uploads/") + fileName; upload.SaveAs(filePath); // 同步保存文件 return Json(new { uploaded = 1, fileName = fileName, url = "/Uploads/" + fileName }); } return Json(new { uploaded = 0 }); }

这种实现存在三个致命缺陷：

1. 同步IO操作阻塞线程池
2. 未做文件哈希去重导致磁盘冗余
3. 缺乏并发控制可能引发资源竞争

2.2 改进方案的技术论证

我们最终采用的方案架构包含以下核心组件：

1. 前端改造：

   • 使用CKEditor的uploadAdapter接口实现分片上传
   • 添加Web Worker支持并行传输

2. 服务端优化：

   • 引入IAsyncEnumerable处理流式上传
   • 采用ImageSharp替代GDI+进行图片处理
   • 基于Redis实现分布式锁控制

3. 存储策略：

   • 七牛云OSS作为主存储
   • 本地磁盘作为灾备缓存

3. 核心实现细节

3.1 前端并行上传改造

关键改造点在于重写CKEditor的上传适配器：

class ChunkedUploadAdapter { constructor(loader) { this.loader = loader; this.chunkSize = 2 * 1024 * 1024; // 2MB分片 } async upload() { const file = await this.loader.file; const chunks = Math.ceil(file.size / this.chunkSize); const uploadId = Math.random().toString(36).substring(2); // 启动Web Worker并行上传 const workers = []; for (let i = 0; i < Math.min(chunks, 4); i++) { // 最大4并发 workers.push(this._uploadChunk(file, i, uploadId)); } await Promise.all(workers); return { default: `/api/upload/complete?uploadId=${uploadId}` }; } _uploadChunk(file, chunkIndex, uploadId) { return new Promise((resolve) => { const worker = new Worker('/js/upload.worker.js'); worker.postMessage({ file, chunkIndex, uploadId, chunkSize: this.chunkSize }); worker.onmessage = (e) => resolve(); }); } }

3.2 服务端异步处理管道

.NET端的核心处理逻辑：

[HttpPost] [DisableRequestSizeLimit] public async IAsyncEnumerable<UploadProgress> UploadChunk( [FromQuery] string uploadId, [FromQuery] int chunkIndex) { var boundary = MultipartRequestHelper.GetBoundary(Request.ContentType); var reader = new MultipartReader(boundary, Request.Body); while (await reader.ReadNextSectionAsync()) { var fileSection = reader.AsFileSection(); if (fileSection != null) { await using var memoryStream = new MemoryStream(); await fileSection.FileStream.CopyToAsync(memoryStream); // 存储分片到临时目录 var tempPath = Path.Combine(Path.GetTempPath(), uploadId); Directory.CreateDirectory(tempPath); await File.WriteAllBytesAsync( Path.Combine(tempPath, $"{chunkIndex}.part"), memoryStream.ToArray()); yield return new UploadProgress { ChunkIndex = chunkIndex, Status = "Received" }; } } }

3.3 图片合并与处理优化

使用ImageSharp进行高性能图片处理：

public async Task<string> CombineAndProcessChunks(string uploadId) { var tempPath = Path.Combine(Path.GetTempPath(), uploadId); var chunks = Directory.GetFiles(tempPath) .OrderBy(f => int.Parse(Path.GetFileNameWithoutExtension(f))); await using var combinedStream = new MemoryStream(); foreach (var chunk in chunks) { var bytes = await File.ReadAllBytesAsync(chunk); await combinedStream.WriteAsync(bytes, 0, bytes.Length); } combinedStream.Position = 0; // 图片压缩与格式转换 using var image = await Image.LoadAsync(combinedStream); await image.SaveAsync(combinedStream, new JpegEncoder { Quality = 80 }); // 上传到云存储 var objectKey = $"{DateTime.Now:yyyyMMdd}/{Guid.NewGuid()}.jpg"; await _ossClient.PutObjectAsync("my-bucket", objectKey, combinedStream); return $"https://oss.mycdn.com/{objectKey}"; }

4. 性能优化关键指标

通过JMeter压测对比（100并发用户，每次上传10张2MB图片）：

5. 踩坑经验与避坑指南

5.1 内存泄漏陷阱

初期测试时发现内存持续增长，最终定位到两个问题：

1. 未及时释放System.Drawing资源
2. MemoryStream未正确Dispose

解决方案：

// 错误示范 using var image = new Bitmap(stream); // GDI+资源不会自动释放 // 正确做法 using var image = await Image.LoadAsync(stream); // 使用ImageSharp

5.2 并发冲突处理

当多个用户同时上传同名文件时，曾出现文件覆盖问题。我们最终采用三级校验：

1. 前端生成文件哈希（使用spark-md5）
2. 服务端检查Redis缓存
3. 最终存储时添加GUID后缀

5.3 超时控制策略

针对大文件上传特别添加了分层超时控制：

services.Configure<IISServerOptions>(options => { options.MaxRequestBodySize = 1024 * 1024 * 500; // 500MB options.AllowSynchronousIO = false; }); services.AddHttpsRedirection(options => { options.HttpsPort = 443; options.RedirectTimeout = TimeSpan.FromMinutes(10); });

6. 扩展优化方向

目前系统还存在两个待优化点：

1. 智能降级策略：当检测到服务器负载过高时，自动切换为有损压缩模式
2. 边缘节点缓存：在CDN边缘节点预生成缩略图，减少回源请求

实际测试中发现，通过预生成以下规格的图片可满足95%的展示场景：

• 1920w (全屏展示)
• 800w (内容配图)
• 300w (缩略图)
• 100w (列表预览)