图片存储下载系统(openresty+ttserver+fastdfs)

先说说这个系统是咋么回事。这个系统有两个接口:

  • 第一个接口是图片链接上传接口,抓取脚本抓取到别人的图片链接后,直接将图片链接上传到这里,然后这个接口将链接生成一个16位的码,然后以这个码为key,图片原始链接为value存入ttserver中,然后将码返回给客户端,客户端下次就用这个码拼接图片链接来访问本张图片
  • 第二个就是图片访问接口了,用拼接好的链接来访问图片,首先会用这个16位的码在ttserver中有没有存本码对应的fastdfs的访问链接,有的话直接返回图片内容;没有的话就表明系统中还没这张图片,然后就进行接下来的工作:先用这个码从ttserver中将原始的图片链接拿出来,然后将图片内容拉回来存入fastdfs中,然后将fastdfs返回的图片存储链接存入ttserver中

大概的流程就是这样的,懒得画图了。

然后说说为啥会用openresty、ttserver、fastdfs这套吧。

  • openresty:非常适合一些逻辑简单但性能要求高的,这里刚好合适,没有啥逻辑处理,只是很简单的流程。openresty
  • ttserver:我用它为啥不用memcache或者redis的原因很简单,它数据存在硬盘,然后热数据在内存中,也很稳定。因为我的图片访问的冷热度很明显的,所以用它就比较好。官方文档TokyoCabinetTokyoTyrant,安装方式见《ttserver安装》
  • fastdfs:号称还不错的小文件存储系统,很多公司在用,但是有一个不好的就是太依赖于操作系统的文件系统了。官方网址 fastdfs fastdfs安装

把上面的串起来基本上就差不多了,差的就是一两个lua脚本了;这里暂时不开源出来。

下面show一下压测结果以及压测的分析

使用的机器是朋友那里借来的,配置和硬盘如下:

  • cpu:Intel(R) Xeon(R) CPU E5620 @ 2.40GHz 16核
  • 内存:48G
  • 硬盘:250G SAS

压测100*100
压测200*100
压测300*100
压测250*300

从上面的图片就可以看出来最大的qps在400的样子,但是就通过top查看负载以及cpu使用情况,还有iostat查看硬盘的情况来看,在到250*300的压的时候CPU的idle居然很高,在94%左右,而%wa很低,在0.1,查看CPU负载情况也很低。在这种上不去的情况下,机器还是这么闲,说明CPU和硬盘都不是问题所在。继续分析连接情况,使用命令(netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’) 查看到了一大堆的TIME_WAIT,好几万,太吓人了。先解决TIME_WAIT的问题 http://www.itdhz.com/post-298.html,然后再来呀要好点了,但是还是上不去。

继续分析,我是本机自己压自己,在我压测的时候也要消耗点端口的,同时建立1W个连接,那么我就得消耗点1W个动态端口,而这台机器的动态端口区是32768 ~~ 61000 (cat /proc/sys/net/ipv4/ip_local_port_range),说明我总共只有28232个端口可用,于是修改压测策略,让并发大一点,然后每个并发的请求量稍微小点,毕竟是图片,也会占用很多网卡资源的。
压测1000*30
压测1000*30

图只存了这么一张,但是也很能说明问题了,qps绝对在1000以上了,如果用另一台机器压的话,绝对能上1500的qps,CPU占用上去了,但是硬盘还是很闲,说明这套系统是根本不吃硬盘的。说明这套东西还是很不错的,不过没试过系统内有大量文件后的速度咋样,不过我也没多少图片存,能存个1KW已经很不错了。

发表评论?

0 条评论。

发表评论


注意 - 你可以用以下 HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>