摘 要

在互联网、多媒体时代，图片无处不在，云计算服务商针对图片垂类的支持欠缺，各个企业重复开发现象严重。图片管理是CPU密集型、IO密集型场景，使用同步处理时延高、流程长，系统高峰期、低峰期负载相差较大，造成资源浪费。

使用异步架构能够很好地解决同步场景下的问题，将处理流程分为核心路径和非核心路径，核心路径使用同步处理，非核心路径通过消息队列异步化处理，缩短处理流程，降低处理时延，异步化还能起到削峰的作用。添加、删除、修改非核心路径的处理，不需改动核心路径代码，增大系统的可维护性和可扩展性。

本论文首先介绍开发背景，分析系统需求，针对功能需求和非功能需求，对系统进行架构设计，最后给出系统的实现和系统测试结果。架构设计将数据状态保存在独立组件中，本系统实现了服务无状态化，可实现水平扩展。

关键词：图片管理；异步架构；消息队列；分布式存储

Abstract

In the age of the Internet and multimedia, image is ubiquitous. The cloud service providers have not met the demand of image management, resulting in enterprise design and build their own system. Image process is an IO and CPU intensive scene. With synchronous model, it will cost a lot of time when the process is complex. And it waste system resources, because system load diff a lot between high and low peak period.

With asynchronous model, problem will be solved automatically. Divide processes into core and secondary. The core process uses synchronous model and the secondary processes are asynchronized by message queue. By simplify process, shorten the reply time and increase the throughput during high peak period. Update, insert or delete secondary processes without modify the code of core process that makes system more robust.

This paper describes the develop background firstly. Then analyses requirements. In order to meet functional and non-functional requirements, designs the architecture of image management system and introduces how to implement. Finally show the system test report. All durable storage maintain in independent components. The services built by this thesis are horizontally expandable.

Key Words：image management system; asynchronous model; message queue; distributed storage

目 录

第1章 绪论 1

1.1研究背景 1

1.2 国内外研究现状 1

1.3 研究目的及意义 2

1.4 课题研究内容 2

第2章 图片管理系统需求分析 4

2.1需求分析概述 4

2.1.1需求分析的目的 4

2.1.2需求分析的流程图 4

2.2开发背景 4

2.3开发目标 5

2.4可行性分析 5

2.4.1经济可行性分析 5

2.4.2工程上可行性分析 6

2.5功能模块需求分析 7

2.5.1用例图设计 8

2.6非功能性需求 10

2.7本章小结 11

第3章 相关理论与技术 12

3.1图片管理系统前端与后端 12

3.2开发工具及环境介绍 13

3.2.1Go编程语言 13

3.2.2MySQL关系型数据库 14

3.2.3Redis缓存系统 14

3.2.4HDFS分布式存储 14

3.2.5NSQ消息队列 16

3.2.6Docker容器部署 16

3.3通信协议 17

3.4开发框架 17

3.4.1消息队列NSQ客户端go-nsq 18

3.4.2HDFS客户端WebHdfs 18

3.4.3MySQL关系型数据库ORM Gorm 18

3.4.4Redis缓存客户端go-redis 18

3.5本章小结 18

第4章 基于异步架构的图片管理网站的后端设计 19

4.1概要设计 19

4.1.1设计思想 19

4.1.2系统功能结构 19

4.1.3层次结构 20

4.2架构设计 21

4.2.1设计模式 21

4.2.2系统组件选择 22

4.2.3系统组件交互 22

4.3处理流程设计 23

4.3.1上传 23

4.3.2删除图片 24

4.3.3下载图片处理流程 25

4.3.4查看用户上传历史 26

4.3.4查看图片元数据 27

4.4数据库设计 28

4.4.1用户信息表设计 28

4.4.2图片元数据表 29

4.5存储系统中Key设计 30

4.5.1Redis键设计 30

4.5.2HDFS键设计 31

4.6消息队列消息格式设计 31

4.6.1图片上传消息设计 32

4.6.2图片删除消息设计 32

4.7本章小结 32

第5章 基于异步架构的图片管理系统后端实现 33

5.1接口调试 33

5.1.1上传图片 33

5.1.2删除图片 34

5.1.3查看上传历史 35

5.1.4查看图片元数据 36

5.1.5下载图片 37

5.2系统运维 38

5.2.1NSQ运维 38

5.2.2HDFS运维 40

5.3系统测试 41

5.3.1上传图片接口 41

5.3.2删除图片接口 42

5.3.3下载图片接口 42

5.4本章小结 42

第6章 总结与展望 44

6.1研究总结 44

6.2研究展望 45

参考文献 46

致谢 47

绪论

本章主要从研究背景、研究目的、研究意义、国内外研究现状、课题研究内容及预期目标几个方面进行相关的阐述。

1.1研究背景

在当今多媒体时代，图片借助其丰富的表达能力，被广泛应用于博客、即时通信、微博、新闻、帖子等场景。多媒体时代从PGC^[1]（专业人员产出内容）逐渐转移到UGC（用户产生内容）。随着智能手机的发展，通过拍照、修图等方式产生图片的成本大大降低，微信、微博、抖音等平台提供用户方便地上传图片。阅读图文时，阅读图片的效率比文字高；即时通信中，用户倾向于使用图片表情进行表达；视频审核中，相比播放完整的视频，更高效的做法是在短时间内审核视频的关键抽帧；人机交互中，图片更容易吸引人的注意力，更好地引导用户操作，提高用户体验。

1.2 国内外研究现状

图片管理是IO密集型、CPU密集型的场景，面临如此场景，需研究出通用的方法解决该场景。在使用小众的APP时，常遇到图片上传、加载缓慢的情况，在极端的情况下，在设定的超时时间内，没有完成图片上传、加载给用户反馈是失败的场景，在高峰期间表现为服务不可用。异步化^[2]处理能够很好地解决这个问题，将图片上传过程做拆分，借助消息队列^[15]，将IO密集、CPU密集型处理异步到不同时间、不同机器中处理，从而达到缩短用户感知到的处理时延，提高用户体验，以及达到削峰的效果，更高效地利用机器资源。

图片管理是IO密集型、CPU密集型的场景。普通图片大小从几KB到几十MB不等，随着摄影技术的进步、显示器分辨率的增加，人们对于高质量的图片的追求，图片的大小、格式将会越来越多。IO密集型主要体现在图片在网络中传输、磁盘读写需要耗费大量的带宽；CPU密集型主要体现在在对图片进行格式转换、水印添加、压缩等处理。Facebook研发的Haystack^[16]针对的是图片的存储的场景，其设计减少磁盘IO从而达到降低系统时延的目的，论文没有讲解异步化架构。

国内外云计算^[3]发展迅速，云计算服务商提供的对象存储、块存储、文件存储、数据库存储服务能够解决最基本的存储问题，但对于用户体验的优化，为图片定制化的服务还不够完善，如添加水印、图片压缩、格式转化等。为图片存储设计一个专门的架构服务是值得的，鉴于其巨大的需求和技术挑战难度。腾讯云提供的行业解决方案中有直播解决方案、电商解决方案，但是缺少对图片这个场景的管理。直接将图片当作一个简单的文件处理还不够合适，因为图片除了基本的二进制数据，其中还需要存储大量的元数据，其数据格式表现为键值对。

小视频的表达能力比图片丰富，比GIF类动态图片多了音频的维度，抖音、微视、快手等产品将小视频推到风口浪尖，是不是小视频发展到一定程度就能完全替代图片呢？仔细研究后发现，每个小视频还需一张封面图片的，作为该视频的一个简单介绍。

在云计算尚未大面积普及下，大部分网站简单地将图片作为一个文件存储在文件系统中，较差的实践是将图片作为二进制流存储在数据库中，比如MySQL支持BLOB、MongoDB^[4]支持GridFS，这种方案不仅对图片大小有限制，比如MongoDB因为行大小限制，存储文件必须小于16MB，对大文件的存储MySQL将其作为文件存储于文件系统中。将文件存储于数据库会增大数据库IO压力，在混合部署情况下，有可能影响到别的业务，造成数据库级别的抖动；增加数据迁移的成本，降低数据库的可扩展性。

小型网站中对于图片的处理大多是同步，一般图片上传步骤可以分为：

1. 用户选择图片进行上传
2. 反向代理、负载均衡将请求路由到具体处理的实例
3. 服务实例收到图片对图片进行压缩，格式转换，水印添加等
4. 元数据存储于数据库
5. 返回处理结果给用户

一般情况下，用户需要等待几秒钟才收到处理结果，在高峰期甚至会造成用户一直上传都无法成功的情况，极大地伤害了用户体验。

1.3 研究目的及意义

本次研究的目的在于，抽象图片的常用处理过程，拆分过程，优化处理流程，将没有依赖关系的过程改为并发处理，将非核心逻辑异步化。从而达到优化用户体验、系统削峰、增加系统可扩展性的目的。提供图片异步化架构的后台通用设计方案和实现，供有需要的开发者做参考。

1.4 课题研究内容

课题研究的主要内容如下：

1. 需求收集，从网上调研、用户调研收集、挖掘图片管理网站^[5]常见需求。
2. 分析需求，设计图片管理流程。
3. 流程优化，将没有依赖关系的步骤并发进行，非核心路径异步化处理。
4. 架构设计，异步通过消息队列实现，调研相关存储系统。
5. 架构实现，编写代码，实现系统相关功能。
6. 结果测试，测试系统的正确性，以及系统的处理时延、并发量、吞吐量等数据。

第2章 图片管理系统需求分析

在实现系统前，对系统的目标用户需求做完整的调研分析是值得的。只有真实地理解了用户需求，才能够确保系统的正确实现，否则仅凭想象猜测用户需求，最后开发出的系统不是用户需要的，造成极大的人力浪费，无法交付能满足用户需求的系统。本章将对图片管理系统需求进行简单地概述，从功能性需求、非功能性需求、可行性分析等三个方面对基于异步架构的图片管理系统进行需求分析。

2.1需求分析概述

软件的需求分析是给后续的设计开发实现提供一个参考模型，描述系统需实现的功能，涉及功能的合理性、规范性与可行性，为后续系统开发提供基础依据。

2.1.1需求分析的目的

分析行业中常见的图片管理场景，调研本系统所需实现的基本功能，业务处理流程等，找出现有常见图片管理系统的不足，为这些不足提供优化的解决方案。需求分析目的是找出竞品的不足，并对其做优化，定位系统的目标用户群，系统运行环境条件及给外界暴露的接口。

2.1.2需求分析的流程图

对图片管理系统调研，总结出基于现有条件能够开发出的基于异步架构的图片管理系统的需求，基于结果分析业务需求，经过分析业务需求，与目标用户明确需求，设计系统的结构和功能。根据需求分析流程图每个步骤。

2.2开发背景

通过调研常见APP图片使用场景，以及用户调研，得出用户常见的需求有：

1. 图片的上传
2. 图片的下载
3. 图片的元信息查询
4. 图片的格式转换
5. 图片的压缩
6. 图片的水印添加
7. 图片的删除

图片被广泛使用，几乎每个网站都离不开图片管理。图片管理是CPU密集型、IO密集型的场景，处理过程中常需花费较长时间，造成用户长时间等待，用户体验大打折扣。系统使用同步处理方式无法达到削峰的目的，在高峰期造成服务不可用。

2.3开发目标

本系统是后端系统，除需考虑用户需求外，还需调研前端开发人员希望后端暴露的接口形式及接口的保证等。后端系统主要考量的标准有：

1. 接口处理时延
2. 接口支持并发度
3. 接口处理失败率
4. 接口的扩展性
5. 系统可维护性
6. 系统的容错性
7. 系统占用的资源

将图片处理流程做优化处理，借助消息队列实现异步化，将非核心路径流程转移到不同时间、不同机器上处理，降低系统的处理时延，高峰期起到削峰的作用。

2.4可行性分析

在真实开发前对需求进行可行性分析的作用是衡量项目的经济价值、工程实现上是否可能及所需成本。

2.4.1经济可行性分析

经济价值通过供需关系体现。

首先阐述需求，图片管理是一个非常普遍的需求，几乎每个网站都有该需求，在电子商务、社区论坛、微博等平台更是图片表达能力以及被阅读数大大高于文字。在智能手机的大面积普及下，用户产出图片的成本越来越低，速度也越来越快，通过微信、微博、头条图文等平台，用户将图片上传到云端并分享的行为越来越多。百度云盘、苹果iCloud提供云存储服务，帮助用户保存记录美好生活的图片，云端图片数据越来越大。

再来描述供给，图片管理系统的设计与实现由网站独立设计与实现的，对于大型网站其背后有复杂的系统架构，处理流程非常完善，但不提供给外界第三方使用，拥有类似需求的公司需独立开发类似的系统，造成大量的人力浪费，重复造轮子情况严重。小公司在人力匮乏，缺少高质量的程序员情况下，简单地将图片存储到本地文件系统，更不好的实现是将文件存储到数据库中，在网站规模小时，问题尚未暴露出来，当规模成长时，往往会遇到可扩展性、数据冗余存储、数据迁移等问题，成为阻碍业务发展的瓶颈。云计算服务提供商提供的是粒度更加粗的服务，比如对象存储、文件存储、块存储及数据库存储，对图片垂类的支持不够完善，比如图片防盗、异步化处理支持。云服务商很大的竞争力是保证存储的水平扩展，将存储直接对接CDN，大大地降低了使用方介入的成本。

综上所述，设计与实现基于异步架构的图片管理系统在经济上是可行的。

2.4.2工程上可行性分析

得益于开源社区的迅猛发展，数据库存储系统、分布式存储系统^[6]、缓存系统^[7]、消息队列系统和容器化管理已经非常完善，对于快速开发一个可靠的系统提供了极大的支持。图片管理系统常见的存储需求有：

1. 图片二进制数据存储
2. 图片元数据存储

图片的二进制信息可以直接存储到分布式存储系统上，或存储到云服务商提供的对象存储服务中。在企业中采用云服务商提供的对象存储服务更加稳定，减少企业的运维成本。但在探索更好的系统架构时，云服务商提供的对象存储服务像是一个黑盒，不了解其中的实现细节，在公网中传输数据会造成大量的流量带宽成本。分布式存储系统中HDFS尤为出色，被大数据生态广泛依赖，Spark、Hive等处理输入、中间结果、最终结果常保存在HDFS中，Kafka消息队列可以将消息dump到HDFS做持久化存储，企业级数据库通常借助HDFS做快照，所以分布式存储可以采用HDFS。

在编程实现中，应面向接口编程，而不是依赖具体实现。这能给系统带来更大灵活性，只需替换具体的实现即可，实现代码复用。在实现中，将存储接口抽象化，后续使用抽象接口作为编程调用对象。

图片的元数据可以分为固定的元数据和某张图片特有的元数据。固有的元数据有图片所有者、图片大小、图片文件名。某张图片特有的元数据是由用户对图片打标签，其表现形式为，地点：武汉、人物：自拍等，此类元数据可帮助用户分类图片，提供多维度的数据记录功能，以便实现图片筛选、搜索等功能。将图片固定的元数据保存在关系型数据库中，将特有的元数据序列化为JSON保存在extra字段中，从而达到系统扩展性要求。更好的实践是将特有的元数据保存在独立的键值对存储系统中，比如RocksDB等。关系型数据库系统开源社区较为成熟的选择为MySQL。

缓存系统将数据短暂存于内存，避免重复频繁地、耗时地去磁盘加载。业界使用最广泛的缓存有2种：

1. 独立内存缓存集群，比如Redis集群、Memcache集群
2. 编程语言实例级别内存缓存，比如HashMap等

缓存系统需要解决的问题是如何降低内存使用、提供内存超时失效机制、如何将Key进行打散负载均衡，怎么防止缓存被击穿，导致数据库存储系统雪崩。对于这种问题，业界已经提供了解决方案，比如Redis有Twemproxy、Redis Cluster机制，能够保证服务的可靠性、负载均衡等；对于内存缓存，可以在负载均衡中将请求按照打散规则路由到特定实例，从而实现LocalCache功能，在负载均衡随机分发请求的场景下，当服务实例数量达到一定阈值后，本地缓存通常不能起太大的作用，因为用户请求打到同一台机器上的可能性太低。

以上是毕业论文大纲或资料介绍，该课题完整毕业论文、开题报告、任务书、程序设计、图纸设计等资料请添加微信获取，微信号：bysjorg。

相关图片展示：