设计一个分布式图像处理系统，用于处理用户上传的海量图片（如万兴照片编辑中的滤镜应用）。系统需要支持实时滤镜处理（如美颜、滤镜），并保证低延迟。请描述系统的架构、并行处理策略以及存储优化方案。

1) 【一句话结论】采用数据依赖驱动的任务拆分与动态资源调度，结合分层缓存和对象存储的分布式架构，通过将图像处理任务拆分为顺序依赖（如面部检测）与并行子任务（如色彩调整），利用消息队列解耦、多节点集群并行计算，以及CDN加速，实现海量图片的实时滤镜处理与低延迟。

2) 【原理/概念讲解】首先，任务拆分需考虑数据依赖：单张图片的滤镜处理可拆分为“面部检测（顺序任务，依赖原始图片）”和“色彩调整、滤镜应用（并行子任务，依赖面部检测结果）”。面部检测需顺序执行（因结果用于美颜参数），后续任务可并行。并行处理时，通过消息队列（如Kafka）分发任务，多节点集群利用多线程/分布式计算框架（如Flink）并行处理子任务。缓存优化：热门滤镜（如“自然光”）的处理结果缓存到Redis（LRU，避免重复计算）；CDN边缘节点缓存静态处理后的图片，用户请求直接从边缘获取。存储优化：原始图片存入对象存储（如MinIO），处理后的图片存入冷区或CDN，减少服务器压力。类比：做菜时，切菜（顺序任务，需先切）和炒菜（并行任务，可同时炒不同菜），切菜完成后通知炒菜开始，提高效率。

3) 【对比与适用场景】

策略/方案	定义	特性	使用场景	注意点
数据依赖驱动的任务拆分	将任务拆分为顺序依赖（需先完成）与并行子任务（可同时执行）	避免串行瓶颈，提高并行效率	美颜、滤镜等复杂处理	需明确数据依赖关系，避免任务错乱
动态资源调度（负载均衡+故障重分配）	负载均衡算法（如轮询+权重）分配任务，节点故障时任务重分配	支持水平扩展，高可用	海量用户上传，高并发	需健康检查，避免故障节点任务堆积
图片格式转换（统一处理格式）	检测JPG/PNG等格式，用libjpeg-turbo解码，转换为PNG（滤镜算法兼容）	确保处理逻辑一致，避免格式差异导致错误	所有图片处理	需考虑格式转换性能，避免影响延迟

4) 【示例】伪代码：
用户上传图片到API Gateway，API Gateway将图片上传请求发送到Kafka（消息队列）。消费者（处理节点）从队列获取图片，首先检测图片格式（如JPG），调用libjpeg-turbo解码为原始像素数据（如PNG）。然后，将任务拆分为：1. 面部检测任务（顺序任务，依赖原始像素数据），结果存入Redis（键为图片ID+“face”）；2. 色彩调整任务（并行任务，依赖面部检测结果，如亮度、对比度调整）；3. 滤镜应用任务（并行任务，如“复古”滤镜，依赖色彩调整结果）。面部检测完成后，Redis通知后续任务（色彩调整、滤镜应用）开始。各并行任务处理结果合并（如滤镜应用结果覆盖色彩调整结果），最终生成处理后的图片。处理后的图片存储到MinIO（冷区），并更新CDN缓存。API返回处理后的图片URL。

5) 【面试口播版答案】（约90秒）
“面试官您好，针对海量图片的实时滤镜处理，我设计的系统核心是采用‘数据依赖驱动的任务拆分+动态资源调度+分层缓存’的架构。用户上传图片后，通过API Gateway进入消息队列，系统将任务拆分为面部检测（顺序任务，依赖原始图片）和多个并行子任务（如色彩调整、滤镜应用）。面部检测结果缓存后，触发后续并行任务，处理结果通过LRU缓存和CDN加速，最终返回处理后的图片。这样，通过合理拆分任务依赖，避免串行瓶颈，同时利用多节点并行计算，目标延迟控制在100ms左右（具体取决于滤镜复杂度和网络状况）。”

6) 【追问清单】

• 问：如何处理任务间的数据依赖？答：用依赖队列，顺序任务完成后通过Redis消息通知后续任务，确保数据传递正确。
• 问：资源调度如何保证负载均衡？答：采用轮询+权重算法，根据节点CPU/内存负载动态调整任务分配，节点故障时自动重分配任务。
• 问：图片格式转换具体怎么做？答：检测JPG/PNG等格式，用libjpeg-turbo解码为PNG，确保滤镜算法对像素数据的处理一致，避免格式差异导致的错误。
• 问：系统如何保证低延迟？答：任务拆分减少单任务计算量，并行处理利用多节点集群，缓存热门滤镜结果，CDN边缘节点加速访问，整体延迟控制在100ms左右。
• 问：如何处理系统故障？答：消息队列持久化存储，消费者自动重试；处理节点健康检查，故障节点任务重新分配，确保任务不丢失。

7) 【常见坑/雷区】

• 忽略数据依赖：直接并行处理所有任务，导致面部检测结果未就绪时，后续任务因数据缺失失败。
• 缓存策略不当：未区分热门与冷门滤镜，导致缓存命中率低，重复计算增加延迟。
• 存储方案未考虑格式转换：使用本地存储存储不同格式的图片，导致处理逻辑不一致，系统不稳定。
• 任务结果合并复杂：未明确合并策略，导致多子任务结果处理逻辑混乱，增加系统复杂度。
• 绝对化延迟表述：声称延迟控制在100ms以内，未说明滤镜复杂度和网络状况的影响，显得不真实。