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

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

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

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

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

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

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

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

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

从上面的图片就可以看出来最大的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个端口可用，于是修改压测策略，让并发大一点，然后每个并发的请求量稍微小点，毕竟是图片，也会占用很多网卡资源的。

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