互联网公司经常会有大量原始图片上传,而且一个原图会在页面以不同尺寸缩略图显示，一般有两种策略生成缩略图，一种在上传图片时，生成需要的多张不同缩略图，另一种是请求指定尺寸的图片时实时生存缩略图片，第一种方式有一定限制，就是需要提前知道所有尺寸的图片，做雍余存储，无形中增加大量文件数量，如果文件系统设计不好，还有可能形成大量文件碎片，而且会消耗大量存储空间，如果前端ui设计改变了图片大小，需要重新生成。而第二种方式更加灵活，但是更消耗cpu资源，属于cpu密集计算型
大吞吐量服务端架构设计要考虑四个技术点
1 编程语言和编译优化
技术选型，是单进程多线程模型(reactor事件机制)，还是多进程模型.
2 图片压缩算法
高效分布式文件存储系统选型。
Linux系统中sysctl参数优化(TCP高级选项设置)
编程语言和编译优化
互联网行业用java开发语言比较多，而且开发人员成熟，而且经验丰富。
高性能网络框架:netty，mina等等，而且资料比较，社区比较活跃。而且有大量内置的图像处理API和算法直接使用.对于jdk自带的一套图片处理库，他的特点是稳定简单，但是对图片处理来说，性能确实很差！离实际线上要求差距很大。不过java方面也提供了类似jni方式支持GraphicsMagick+im4java处理图像，但是要原生态支持openmpi,tbb，opencv等就比较繁琐了，要用jni方式调用大量动态或静态库。一个性能问题，二是如果出现内存问题也不好控制。
C语言:
1.有成熟图像处理库GraphicsMagick和opencv，
2.有可以很容易实现多进程模式。
3.容易用其他编译器做优化，比如用intelicc编译，可以大幅度提高性能。
4.多进程中每个进程方面绑定到每个cpu核上，实现操作系统每个cpu核上队列相同，均衡调度，更容易发挥目前多核cpu性能！
下面说一下单进程多线程模型
主线程负责侦听listen，注册accept和新进来连接,然后把连接socket转交给workthreadpool进行读写事件注册，计算逻辑处理
reactor事件机制:
Reactor释义“反应堆”，是一种事件驱动机制。和普通函数调用的不同之处在于：应用程序不是主动的调用某个API完成处理，而是恰恰相反，Reactor逆置了事件处理流程，应用程序需要提供相应的接口并注册到Reactor上，如果相应的时间发生，Reactor将主动调用应用程序注册的接口，这些接口又称为“回调函数”.
Reactor模式的优点
Reactor模式是编写高性能网络服务器的必备技术之一，它具有如下的优点：1）响应快，不必为单个同步时间所阻塞，虽然Reactor本身依然是同步的；2）编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；3）可扩展性，可以方便的通过增加Reactor实例个数来充分利用CPU资源；4）可复用性，reactor框架本身与具体事件处理逻辑无关，具有很高的复用性；
3 多进程服务器
1每个进程处理多个connection，使用epoll事件驱动来管理这些连接,多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。
2master由信号驱动，worker由epoll驱动（当然信号会让epoll_wait返回），有更好的容错性，如果其中一个进程挂了或产生core,master收到相关信号后，会同时重启一个进程，并同时发送出相关监控信息，也不会导致不能提供服务,。
3多进程用来利用多CPU硬件，所以按照业务边界来划分进程，或者就按CPU个数配置。
4每个进程是单线程的：所有IO相关操作都是全异步处理方式，避免多线程切换和锁机制开销。
5进程之间抢占epoll资源时，仅用一个轻量级的共享内存锁，循环依次把连接事件放入队列，然后循环处理每个客户端的连接请求和逻辑处理。
6高性能：服务器若支持多CPU或超线程，多线程无法完全利用机器性能，多进程则可以让服务器满载.
4 图片压缩算法(jpeg,png,gif)
目前图像压缩算法已经成型，而且基本上都是搞数学方面的大牛发明的，
关于图像处理方面可以参考如下:
图片压缩或处理是一个非常消耗cpu的操作计算量非常大，因为要进行大量矩阵,傅立叶变换、沃尔什变换、离散余弦变换,图像噪声处理等变换或计算.目前高性能图像处理开源软件有2种GraphicsMagick和opecv。
GraphicsMagick:
GraphicsMagick号称图像处理领域的瑞士军刀。短小精悍的代码却提供了一个鲁棒、高效的工具和库集合，来处理图像的读取、写入和操作，支持超过88种图像格式，包括重要的DPX、GIF、JPEG、JPEG-2000、PNG、PDF、PNM和TIFF等等。
通过使用OpenMP可是利用多线程进行图片处理，增强了通过扩展CPU提高处理能力。
注意：但是GraphicsMagick启动多线程时，处理速度虽然加快了，但是cpu确大幅飙升。
Opencv:
OpenCV于1999年由Intel建立，如今由WillowGarage提供支持。OpenCV是一个基于[1]（开源）发行的跨平台计算机视觉库，可以运行在Linux、Windows和MacOS操作系统上。它轻量级而且高效——由一系列C函数和少量C++类构成，同时提供了Python、Ruby、MATLAB等语言的接口，实现了图像处理和计算机视觉方面的很多通用算法。[2]最新版本是2.4.5。
OpenCV拥有包括300多个C函数的跨平台的中、高层API。它不依赖于其它的外部库——尽管也可以使用某些外部库。
注意：opencv目前支持jpeg,tiff,png,但是由于版权和法律方面原因不支持gif图像处理，png只是有限支持，图像压缩时会变形或变模糊。
GraphicsMagick与Opencv比较优缺点:
GraphicsMagick支持图像多，覆盖面全，几乎所有常见图像格式.压缩质量高
Opencv支持有限的图像处理，覆盖面不全，经过大量压力测试综合比较，但是压缩性能确比GraphicsMagick快一倍多。
综合两者的优点：需要把两者结合起来混合处理不同图像，以达到图像处理最佳性能。
5 高效分布式文件存储系统选型
互联网图片文件存储，一般考虑带宽，存储空间方面压力，经过压缩大小不会2MB。因此存储方案就有多种选择，既可以选择传统mysql数据库，也可以用成熟的分布式文件系统.下面就来说说他们的不同和优缺点。
用mysql做存储：
1.互联网公司都用mysql的丰富经验，技术成熟，众多人都会用mysql，而且还有专业的DBA团队来维护。
2.Mysq性能稳定，单台机器加上内存，基本能满足QPS性能要求。
3.存储图片的表结构属性少，结构简单，一般访问时只需要查询主键就可以了，不需求简历额外的索引。
4.去中心化设计，两台服务器为一组，双写随机读(任意一台服务器),服务器为raid5模式。
5.系统扩容，每当当前服务器存储空间不足，需要增加服务器扩容时，都需要成倍增加服务器数量.
6 用分布式文件做存储
1.一般是直接使用成熟开源产品或自主研发，使用开源产品，开发成本低，学习成本高，需要专门花费一些进行研究或学习。还要自己来维护。自主研发，时间周期长，投入成本更高，但可控性更强。能进行大量性能优化和调整，或许能节省一些服务器资源。
2.同等条件下分布式文件系统性能一般会比mysql等关系型数据库高3-5倍，因为它不需求进行B+Tree（时间复杂度）分页查找，文件在上传时，其生成的文件名就包含了大量文件具体位置信息，一般o(1)时间就能准备定位。而且是顺序一次性读取。不想B+Tree按页式存储，可能要多次读取多页数据，而且每条记录需求存储额外信息，进行事物回滚处理，比较浪费存储空间。
3.中心化设计(一般为metaserver和dataserver两类服务器组集群)，两或三台服务器为一组，双写随机读(任意一台服务器),可以不用raid5模式。
4.系统扩容，每当当前服务器存储空间不足，可以轻易做到线性扩展，只需要增加一组服务器就可以了。明显在成本上具有优势。
Linux系统中sysctl参数优化(TCP高级选项设置)
服务器在高并发时，会创建大量连接，这就需要设置TCP相关参数来提供服务器性能。
1.文件描述符最大数调整。
修改vi/etc/security/limits.conf值
在里面添加一行
*-nofile65535
保存重启，再用命令ulimit-n可发现文件描述符由默认变成65535了
2.高负载linux服务器的内核调优
vi/etc/sysctl.conf,修改内核参数：
kernel.shmall=268435456
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_fin_timeout=30
net.ipv4.tcp_keepalive_time=1200
net.ipv4.ip_local_port_range=102465000
net.ipv4.tcp_max_tw_buckets=5000
net.ipv4.tcp_max_tw_buckets=5000
net.ipv4.tcp_fin_timeout=30
net.ipv4.tcp_keepalive_time=300
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
net.ipv4.ip_local_port_range=500065000
net.ipv4.tcp_mem=78643210485761572864
net.core.wmem_max=873200
net.core.rmem_max=873200
net.ipv4.tcp_wmem=8192436600873200
net.ipv4.tcp_rmem=32768436600873200
net.core.somaxconn=256
net.core.netdev_max_backlog=1000
net.ipv4.tcp_max_syn_backlog=2048
net.ipv4.tcp_retries2=5
net.ipv4.tcp_keepalive_time=500
net.ipv4.tcp_keepalive_intvl=30
net.ipv4.tcp_keepalive_probes=3
net.ipv4.conf.lo.arp_ignore=0
net.ipv4.conf.lo.arp_announce=0
net.ipv4.conf.all.arp_ignore=0
net.ipv4.conf.all.arp_announce=0
3.参数说明：net.ipv4.tcp_syncookies=1
#表示开启SYNCookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse=1
#表示开启重用。允许将TIME-WAITsockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle=1
#表示开启TCP连接中TIME-WAITsockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout=30
#表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。
net.ipv4.tcp_keepalive_time=1200
#表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。
net.ipv4.ip_local_port_range=102465000
#表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1024到65000。
net.ipv4.tcp_max_tw_buckets=5000
#表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，
#TIME_WAIT套接字将立刻被清除并打印警告信息。默认为180000，改为5000。
7 架构
整体架构如下：
可以看到，笔者采用了通用的分层架构设计模式。
- file storage存放着原始的图片数据。
- image server用于图片的处理，同时进行图片的cache。
- nginx作为统一的入口，同时也作为cache。
当用户请求一张图片的缩略图的时候，如果该图片不存在于nginx的缓存中，则nginx根据图片的fileid 通过consistent hash路由到对应的image server上面去处理，如果image server仍然没有该图片，则会从file storage下载。
分层架构有一个很好的地方在于系统的可扩展性，同时我们也可以在加入一些中间层，提高cache的命中率，譬如我们就可以在image server与nginx之间引入一个cache层。不过鉴于我们的系统主要用于企业内部，不会出现图片数据量过大的情况，所以上面这套分层设计已经足够了。
nginx try_files
如果本地cache不存在，则去后台服务器取数据。对于这套逻辑，nginx可以通过try_files很好的处理，譬如:
location /abc.png {
root /data/image/;
try_files $uri @fetch;
}
location @fetch {
proxy_pass http://up_imageserver$request_uri;
}
首先try_files会尝试在本地获取对应的文件，如果没有找到，则会内部跳转到fetch这个location去远程获取数据。
8 何时处理缩略图
既然是缩略图，那么何时生成缩略图就是需要考虑的问题了。通常来说，缩略图的生成会有两种方式：
- 上传生成
当用户上传一张图片之后，系统自动为该图片生成对应的固定格式缩略图，然后将原图与缩略图一起存放到file storage里面去。这方面主要有facebook的Haystack系统。
- 实时生成
当用户上传一张图片之后，只保留该图片的原始数据，当请求该图的缩略图时，如果cache中不存在，由image server动态生成。这方面可以参考淘宝的图片存储介绍。
对于笔者来说，实际使用的是第二种方法，主要有以下几个原因的考量：
- 对于实时生成的缩略图我们可以灵活的指定其大小，而不像上传生成那样只有预先定义的width和height。
- 存储成本，额外存储缩略图会占用很大的存储空间，而且存放到file storage里面还会有冗余备份的问题，更加浪费。
- 协同图片的冷热性问题，最近最热的图片铁定是最频繁访问的，尤其是在多人协同情况下面，而这些图片缩略图是有缓存的，不需要每次都通过原图生成，性能有保证。
9 如何处理缩略图
既然选择实时生成缩略图，那么如何快速生成缩略图就是笔者需要考虑的问题了。这里笔者使用graphicsmagick来生成缩略图，网上有太多介绍，这里不再累述。
10 安全
生成缩略图之后，如何保证该图片的安全访问也是一个需要关注的问题。笔者考虑了如下解决方案：
- 签名，任何缩略图的url都是经过签名，因为签名是通过登陆用户自身的access id和security key进行的，并且有时效性，所以外界很难伪造。或者，可以使用简单的HttpAccessKeyModule来进行访问控制。
- nginx HttpRefererModule，只允许特定domain的请求访问。
11 存储
对于如何存储大量的图片小文件，笔者觉得可以如下考虑：
- 对于文件最终存放的file storage，业界有很多好的分布式解决方案，譬如TFS，mogilefs等，如果想自己造一个轮子，也很不错。
- 对于图片的cache，因为cache的存储文件量级我们是可以控制的，所以这里可以考虑直接使用通常的文件系统存储。
但需要注意的是，单个目录下面文件数量不能过多，目录的层次也不能过深，不然会导致很严重的性能瓶颈。为了解决上述问题，笔者建立了三层目录结构，首层100个文件夹，以1 - 100命名，每个文件夹下面1000个文件夹，以1 - 1000命名，对于任意的图片文件，根据其实际的文件名通过两次hash到特定的目录下。
本文链接 http://tec.5lulu.com/detail/105k2n1e6z65g8s6c.html