架构设计：系统存储（20）——图片服务器：需求和技术选型（2）

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！ 

3-5、其它技术选型说明

3-5-1、关于关系型数据库

关于持久化存储的数据库技术要注意一点，实际上它并不是图片服务的必要组件。例如，我们在进行设计时可以将图片访问的URL地址直接对应图片文件在服务器上的存储地址，并按照一定的规则将图片文件重命名成一个系统中唯一的文件名，最后再删除Redis和Nginx Proxy Cache中可能存在的历史文件数据。这样就算没有数据库技术，也可以保证图片服务正常工作。

但是在上文描述的图片服务需求中，产品还明确要求需要对用户上传的规律、活跃度等状态信息进行统计，需要对图片的物理磁盘读操作频度进行统计分析，所以一些结构化的数据还是需要做持久化存储的。就拿图片的每日访问情况来说，当我们为通过Flmue收集了Nginx的访问日志，并送入到一个独立的日志分析系统中进行处理后，类似单个用户每一天对图片数据的访问数量、每张图片在每一天的访问数量这样的分析结果还是要存入到数据库中以备后续的统计分析——无论是选用关系型数据库MySQL、SQL Server或者非关系型数据库Mongodb、Apache Cassandra。

也就是说，实际上要实现完整的图片服务系统的话还是离不开使用数据库技术的，但是这个基本上属于一个边缘选型，完全可以根据您所在公司某种默认规定的数据库技术作为依据。

3-5-2、关于Nginx的补充

• 关于Nginx Proxy Cache

  Nginx的Proxy Cache缓存采用内存索引 + 物理磁盘存储的工作方式，所以为了进一步提高Proxy Cache的工作性能，在为Proxy Cache指定工作目录时，最好指定到一个独立挂载点上，并且这个挂载点的底层物理介质最好为SSD 固态磁盘 + RIAD 5磁盘阵列。另外在后文我们介绍Proxy Cache配置时，还会讨论Proxy Cache的一些注意细节。

• 关于Image_Filter模块
  有的读者可能会问，什么我们不直接基于Nginx提供的第三方模块Image_Filter作为图片处理的基础呢？这个模块也可以实现图片的缩放、裁剪、翻转、特效等操作。是的， 如果您的系统对图片处理的需求不高，完全可以使用Image_Filter来动态处理图片请求 。Image_Filter使用C/C++语言完成，在完成单张图片同样的特效要求的前提下，处理性能也比使用JAVA原生的Image I/O API要高。但Image_Filter可以提供的图片效果也是有限，例如Image_Filter提供的特效方面只有透明度、锐化、旋转、变更图片质量等操作，但如果系统中有诸如效果增强、背景虚化等这样的图片特效要求，那还是只能有开发人员自行编程解决；Image_Filter虽然可以为图片加水印效果，但是要求水印图片背景必须透明（有Alpha通道，后文会讲到）；最后，这个图片服务系统是一个对本专题和其他几个专题所讲解的架构知识的综合应用，当然最好介绍一下自己编程做做图片处理的相关知识。

4、关键技术点考量

4-1、图片处理中的责任链模式

在图片处理系统的首个版本中，我们计划先提供诸如图片等比例缩放、图片中心点裁剪、图片白化、图片文字水印等基本功能，但是为了保证软件设计部分能够在后续版本方便进行功能扩展，我们需要找到一种符合功能特点的行为模式，作为基本的设计模式。

首先，我们在首期提供的这些功能并不能要求使用者（客户端）按照某种操作顺序执行，而应该由使用者自行确定操作顺序。什么意思呢？我们不能规定使用者必须先缩放图片才能为图片添加水印，也不能规定要进行图片白化，就不能进行图片裁剪。而应该让使用者像使用PS软件一样——可以首先进行图片裁剪，然后再进行白化，最后再添加水印；也可以先向图片增加文字水印，然后再进行图片等比例缩放操作。