互联网公司高并发图片存储服务架构设计一

非常感谢http://blog.csdn.net/lizhitao/article/details/9323137

互联网公司高并发图片处理中间层服务架构设计                                 

                              目录

背景 1

大吞吐量服务端架构设计要考虑四个技术点 1

编程语言和编译优化 2

下面说一下单进程多线程模型 2

多进程服务器： 3

图片压缩算法(jpeg,png,gif) 4

高效分布式文件存储系统选型 4

Linux系统中sysctl参数优化(TCP高级选项设置) 5

背景

本文分析互联网公司高并发高吞吐量(访问)下图片处理(主要是图片压缩或变换)中间层服务架构设计，互联网公司经常会有大量原始图片上传,而且一个原图会在页面以不同尺寸缩略图显示，一般有两种策略生成缩略图，一种在上传图片时，生成需要的多张不同缩略图，另一种是请求指定尺寸的图片时实时生存缩略图片，第一种方式有一定限制，就是需要提前知道所有尺寸的图片，做雍余存储，无形中增加大量文件数量，如果文件系统设计不好，还有可能形成大量文件碎片，而且会消耗大量存储空间，如果前端ui设计改变了图片大小，需要重新生成。而第二种方式更加灵活，但是更消耗cpu资源，属于cpu密集计算型，以上两种方式优缺点一目了然，如果选择就要看公司服务器资源侧重点了。 

我只是把个人见解做一下分析，不准确地方欢迎大家指出。

大吞吐量服务端架构设计要考虑四个技术点

编程语言和编译优化

技术选型，是单进程多线程模型(reactor事件机制)，还是多进程模型.

图片压缩算法

高效分布式文件存储系统选型。

Linux系统中sysctl参数优化(TCP高级选项设置)

编程语言和编译优化

互联网行业用Java开发语言比较多，而且开发人员成熟，而且经验丰富。

高性能网络框架:netty，mina等等，而且资料比较，社区比较活跃。而且有大量内置的图像处理API和算法直接使用.对于jdk自带的一套图片处理库，他的特点是稳定简单，但是对图片处理来说，性能确实很差！离实际线上要求差距很大。不过java方面也提供了类似jni方式支持GraphicsMagick+im4java处理图像，但是要原生态支持openmpi,tbb，OpenCV等就比较繁琐了，要用jni方式调用大量动态或静态库。一个性能问题，二是如果出现内存问题也不好控制。

C语言:

1.有成熟图像处理库GraphicsMagick和opencv，

2.有可以很容易实现多进程模式。

3.容易用其他编译器做优化，比如用intel icc编译，可以大幅度提高性能。

4.多进程中每个进程方面绑定到每个cpu核上，实现操作系统每个cpu核上队列相同，均衡调度，更容易发挥目前多核cpu性能！

下面说一下单进程多线程模型

主线程负责侦听listen，注册accept和新进来连接,然后把连接socket转交给work thread pool进行读写事件注册，计算逻辑处理

reactor事件机制:

Reactor释义“反应堆”，是一种事件驱动机制。和普通函数调用的不同之处在于：应用程序不是主动的调用某个API完成处理，而是恰恰相反，Reactor逆置了事件处理流程，应用程序需要提供相应的接口并注册到Reactor上，如果相应的时间发生，Reactor将主动调用应用程序注册的接口，这些接口又称为“回调函数”.

 Reactor模式的优点

Reactor模式是编写高性能网络服务器的必备技术之一，它具有如下的优点：
    1）响应快，不必为单个同步时间所阻塞，虽然Reactor本身依然是同步的；
    2）编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；
    3）可扩展性，可以方便的通过增加Reactor实例个数来充分利用CPU资源；
    4）可复用性，reactor框架本身与具体事件处理逻辑无关，具有很高的复用性；

多进程服务器：

1 每个进程处理多个connection，使用epoll事件驱动来管理这些连接,多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。

2 master由信号驱动，worker由epoll驱动（当然信号会让epoll_wait返回），有更好的容错性，如果其中一个进程挂了或产生core,master收到相关信号后，会同时重启一个进程，并同时发送出相关监控信息，也不会导致不能提供服务,。

3 多进程用来利用多CPU硬件，所以按照业务边界来划分进程，或者就按CPU个数配置。

4 每个进程是单线程的：所有IO相关操作都是全异步处理方式， 避免多线程切换和锁机制开销。

5 进程之间抢占epoll资源时，仅用一个轻量级的共享内存锁，循环依次把连接事件放入队列，然后循环处理每个客户端的连接请求和逻辑处理。

6 高性能：服务器若支持多CPU或超线程，多线程无法完全利用机器性能，多进程则可以让服务器满载.

图片压缩算法(jpeg,png,gif)

目前图像压缩算法已经成型，而且基本上都是搞数学方面的大牛发明的，

关于图像处理方面可以参考如下:http://blog.csdn.NET/lizhitao/article/details/9317521

图片压缩或处理是一个非常消耗cpu的操作计算量非常大，因为要进行大量矩阵,傅立叶变换、沃尔什变换、离散余弦变换,图像噪声处理等变换或计算.目前高性能图像处理开源软件有2种GraphicsMagick和opecv。

GraphicsMagick:

GraphicsMagick号称图像处理领域的瑞士军刀。 短小精悍的代码却提供了一个鲁棒、高效的工具和库集合，来处理图像的读取、写入和操作，支持超过88种图像格式，包括重要的DPX、GIF、JPEG、JPEG-2000、PNG、PDF、PNM和TIFF等等。

通过使用OpenMP可是利用多线程进行图片处理，增强了通过扩展CPU提高处理能力。

注意：但是GraphicsMagick启动多线程时，处理速度虽然加快了，但是cpu确大幅飙升。

Opencv:

OpenCV于1999年由Intel建立，如今由Willow Garage提供支持。OpenCV是一个基于[1]（开源）发行的跨平台计算机视觉库，可以运行在Linux、Windows和Mac OS操作系统上。它轻量级而且高效——由一系列 C 函数和少量 C++ 类构成，同时提供了Python、Ruby、MATLAB等语言的接口，实现了图像处理和计算机视觉方面的很多通用算法。[2]最新版本是2.4.5。

OpenCV 拥有包括 300 多个C函数的跨平台的中、高层 API。它不依赖于其它的外部库——尽管也可以使用某些外部库。

注意：opencv目前支持jpeg,tiff,png,但是由于版权和法律方面原因不支持gif图像处理，png只是有限支持，图像压缩时会变形或变模糊。

GraphicsMagick与Opencv比较优缺点:

GraphicsMagick支持图像多，覆盖面全，几乎所有常见图像格式.压缩质量高

Opencv支持有限的图像处理，覆盖面不全，经过大量压力测试综合比较，但是压缩性能确比GraphicsMagick快一倍多。

综合两者的优点：需要把两者结合起来混合处理不同图像，以达到图像处理最佳性能。

高效分布式文件存储系统选型

互联网图片文件存储，一般考虑带宽，存储空间方面压力，经过压缩大小不会2MB。因此存储方案就有多种选择，既可以选择传统MySQL数据库，也可以用成熟的分布式文件系统.下面就来说说他们的不同和优缺点。

用mysql做存储：

1.互联网公司都用mysql的丰富经验，技术成熟，众多人都会用mysql，而且还有专业的DBA团队来维护。

2.Mysq性能稳定，单台机器加上内存，基本能满足QPS性能要求。

3.存储图片的表结构属性少，结构简单，一般访问时只需要查询主键就可以了，不需求简历额外的索引。

4.去中心化设计，两台服务器为一组，双写随机读(任意一台服务器),服务器为raid5模式。

5.系统扩容，每当当前服务器存储空间不足，需要增加服务器扩容时，都需要成倍增加服务器数量.



用分布式文件做存储

1.一般是直接使用成熟开源产品或自主研发，使用开源产品，开发成本低，学习成本高，需要专门花费一些进行研究或学习。还要自己来维护。自主研发，时间周期长，投入成本更高，但可控性更强。能进行大量性能优化和调整，或许能节省一些服务器资源。

2.同等条件下分布式文件系统性能一般会比mysql等关系型数据库高3-5倍，因为它不需求进行B+Tree（时间复杂度 ）分页查找，文件在上传时，其生成的文件名就包含了大量文件具体位置信息，一般o(1)时间就能准备定位。而且是顺序一次性读取。不想B+Tree按页式存储，可能要多次读取多页数据，而且每条记录需求存储额外信息，进行事物回滚处理，比较浪费存储空间。

3.中心化设计(一般为meta server和data server两类服务器组集群)，两或三台服务器为一组，双写随机读(任意一台服务器),可以不用raid5模式。

4.系统扩容，每当当前服务器存储空间不足，可以轻易做到线性扩展，只需要增加一组服务器就可以了。明显在成本上具有优势。



Linux系统中sysctl参数优化(TCP高级选项设置)

服务器在高并发时，会创建大量连接，这就需要设置TCP相关参数来提供服务器性能。

1.文件描述符最大数调整。

   修改 vi /etc/security/limits.conf 值

      在里面添加一行

      * - nofile 65535

    保存重启，再用命令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 = 1024 65000

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 = 5000 65000

net.ipv4.tcp_mem = 786432 1048576 1572864

net.core.wmem_max = 873200

net.core.rmem_max = 873200

net.ipv4.tcp_wmem = 8192 436600 873200

net.ipv4.tcp_rmem = 32768 436600 873200

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

#表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；

net.ipv4.tcp_tw_reuse = 1

#表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

net.ipv4.tcp_tw_recycle = 1

#表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为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 = 1024    65000 

#表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1024到65000。

net.ipv4.tcp_max_tw_buckets = 5000

#表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，

#TIME_WAIT套接字将立刻被清除并打印警告信息。默认为180000，改为5000。

后续会分享一下pic server中间层服务器如何设计的，其100-200KB设置缩略图尺寸100*75，实时压缩（计算）如何达到单台机器1000左右/QPS的

硬件服务器配置:戴尔PowerEdge R710 八核16线程     Xeon E5620 2.4GHz