图片服务架构以及fastDFS的部分特性

感谢那些关注我的朋友，谢谢你们的支持。心情一鸡冻，决定再来一发 :lol: ，今天分享的内容主要是围绕图片服务架构。如果有哪些地方写的不对，欢迎吐槽！

首先，我们还是确定一下此次的路线

1.现有业务背景
2.为业务而制定的架构
3.fastdfs的一些特性
4.未来可能面临的问题


[b] 一、现有业务背景[/b]
目前，据我所知，绝大多数互联网公司都会面临图片存储的问题。现在先描述下新的业务需求：
1.每天的图片pv量kw左右
2.从流量水平看，峰值是k req/s
3.图片大小在30k左右，图片分辨率固定几种，图片格式固定
4.图片日增量几十w
5.客户端接口支持
补充.业务自身的上传限制，查看限制不在此讨论范围内
[b]二、为业务而制定的架构[/b]
[img]http://dl2.iteye.com/upload/attachment/0112/2788/2bab9b66-2769-3327-8f0c-d83dc9507829.jpg[/img]
备注：
F5会根据请求路径的不同(主要是group分组)将请求分发到不同的存储节点
nginx+fastdfs-nginx-module 模块：首先在本地文件存储中寻找文件发现文件存在即立即返回;如文件不存在则链接Thacker服务器请求文件地址
TrafficServer 只是用做单机缓存
FastDFS （4.0.6） 分布式文件系统，存储图片
之前的存储采用的是emc，由于业务增长，需要分布式的且扩展方便的文件系统，最后采用了fastDFS。（分布式文件问题详见[url=http://blog.csdn.net/it_yuan/article/details/8980849]分布式文件系统的原理[/url] ）
[b]三、fastdfs的一些特性[/b]
主要是轻量级、不分块、扩展方便等特点，在此还是引用下鱼大的那篇文章
[url=http://zhuanjiao520.iteye.com/blog/2248784]分布式文件系统 FastDFS[/url]
[b]四、未来可能面临的问题[/b]
扩容方案，当增加一个分组的时候，热点数据基本分布在这个分组上，一次上两台机器能不能扛住，需要观察
安全问题，客户端做限制，存储的文件只保存原图，所有的访问请求都必须加水印，同时不能访问原图；服务端做防盗链限制，nginx实现
降级策略，缓存默认处理结果
监控，包括容量，负载，错误日志 等

【结束语】
感谢你们的鼓励，我们是攻城狮，我们敬畏这个行业！