背景
在 Uber Eats 优食的规模上，图像处理是运营的必要条件。该平台管理着数亿张产品图片，每小时有数百万次更新流经系统。每张图像都有成本：网络带宽、处理时间、存储空间和 CDN 占用空间。随着 Uber Eats 优食从餐厅扩展到杂货、酒类和家居用品，形象渠道开始紧张。例如，单一产品（例如一罐可口可乐）可能会出现在数千个店面中。但是，后端将每次外观都视为新上传。没有跨商家共享资产的概念。每次上传都会触发新的下载、新的转换和新的存储作，即使图像与系统中已有的图像相同。旧方法还假设 URL 更改将伴随任何图像更改。如果 URL 保持不变，它不会跟踪内容更新。此被阻止的图像会刷新，从而导致尴尬的解决方法。工程目标很明确：减少不必要的处理，降低存储和 CDN 成本，并尽可能重用现有工作。在本文中，我们将了解优步如何实现数亿张图像重复数据删除的目标。
旧系统的局限性
原始图像管道基于一个简单的假设运行：如果 URL 是新的，则图像必须是新的。如果 URL 相同，请跳过所有内容。但是，没有机制来检测两个不同的 URL 是否指向同一图像。系统将每个传入 URL 视为唯一，即使底层图像字节相同。因此，由不同商家上传或在不同上下文中列出的同一图像将被多次下载、处理和存储。
请参见下图：
更糟糕的是，当 URL 保持不变时，系统无法检测到内容更改。如果商家在未修改 URL 的情况下更新了图像，系统会完全忽略它。没有验证，没有重新处理，没有缓存失效。
这有几个主要缺点：
- 冗余映像下载导致网络使用量膨胀。
- 不必要的处理周期推高了计算成本。
- 重复的 CDN 条目推高了存储和交付成本。
新图像处理管道
重新设计的图像管道将焦点从 URL 转移到实际图像内容。系统现在不再依赖 URL 更改等外部信号，而是使用内容可寻址缓存。每个图像都由其字节的加密哈希来标识。如果两个图像相同，则它们的哈希值将匹配，无论它们来自哪里或使用什么 URL。此更改使系统能够跨上传、商家和目录更新重复使用工作，而无需依赖脆弱的假设。
新的映像服务遵循三个主要路径，具体取决于它对映像的了解：
- 已知且已处理： 查找图像哈希和处理规范。如果两者都缓存了，请立即返回处理后的图像。
- 新的和未处理的： 下载图像，计算哈希值，应用转换，存储结果，然后返回它。
- 已知但尚未使用当前规范进行处理： 使用其哈希值检索原始图像，应用请求的处理，并存储输出。
请参阅下图，其中显示了三个流：
为了支持这些流，系统维护三个逻辑映射，如下图所示：
每个地图都处理一个不同的问题：识别内容、链接处理后的输出以及跟踪原始资产。
存储详情如下：
- 图像，包括原始图像和经过处理的变体，都存储在 Terrablob 中，这是 Uber 以 Amazon S3 为蓝本的 blob 存储系统。
- 元数据（例如映射和处理规范）存储在 Docstore 中，Docstore 是一个基于文档的键值存储，针对快速查找进行了优化。
加工处理规范
每个图像转换请求都包含一个处理规范，该规范定义了应如何处理图像。这包括：
- 输入约束，例如最小分辨率或可接受的文件类型。
- 输出格式，如 JPEG 或 PNG。
- 调整大小指令，包括目标尺寸或纵横比。
图像哈希和处理规范共同形成一个唯一键。如果之前处理过该组合，系统可以立即返回结果，而无需执行任何工作。此缓存机制同样适用于成功的转换和已知故障。
错误被视为一等结果。例如，如果上传的图像太小而无法满足请求的分辨率，系统会使用相同的 hash-plus-spec 键在“已处理的图像映射”中记录失败。下次该映像具有相同的规格时，系统会跳过下载和转换并返回缓存错误。
这可以避免在同一错误输入上重复失败，并防止在保证失败的请求上浪费计算周期。它还使跨客户端的错误报告更快、更一致。
处理稳定 URL 背后的图像更新
并非每个图像更新都带有新的 URL。商家通常会替换 URL 后面的内容，而不更改 URL 本身。在旧系统中，这意味着更新被静默忽略。系统假设已知 URL 始终指向同一图像，这导致提供过时或不正确的数据。
为了解决这个问题，新管道使用 HTTP Last-Modified 标头来检测同一 URL 后面的图像是否发生了变化。在图像处理过程中：
- 系统会检查 URL 映射中存储的上次修改值。
- 它将此值与图像服务器返回的当前 Last-Modified 值进行比较。
- 如果时间戳已更改，则会重新下载并重新散列映像。
- 如果时间戳相同，则系统使用缓存的哈希值并跳过下载。
请参见下图：
这种方法允许商家保持稳定的 URL，同时仍提供更新的内容。映像管道会尊重这些更新，而不会盲目地重新处理每个请求。它还避免了在没有任何变化的情况下进行不必要的工作。
结论
新的内容可寻址图像管道将嘈杂的冗余工作流程转变为精益、高吞吐量的系统。
- 中位延迟为 100 毫秒，P90 不到 500 毫秒，即使在重负载下也能快速提供图像。
- 现在，超过 99% 的请求无需重新处理图像即可完成。这是性能和效率的明显胜利。
通过在内容级别进行重复数据删除，系统避免了重复下载、转换和存储。它会优雅地处理图像更新，即使商家重复使用 URL。这些变化显着降低了基础设施需求，同时提高了可靠性。也许最令人印象深刻的是交付速度。新架构在不到两个月的时间内推出，但支持 Uber Eats 优食容量最大的数据路径之一。这是一个强有力的例子，说明核心系统的有针对性的改进如何释放更广泛的产品速度，尤其是当解决方案快速、可扩展且易于推理时。
今天先到这儿，希望对AI云原生，技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管理，信息安全，团队建设 有参考作用 , 您可能感兴趣的文章:
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变 如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：
作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
