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

    感谢那些关注我的朋友，谢谢你们的支持。心情一鸡冻，决定再来一发 ，今天分享的内容主要是围绕图片服务架构。如果有哪些地方写的不对，欢迎吐槽！
   
    首先，我们还是确定一下此次的路线
   
    1.现有业务背景
    2.为业务而制定的架构
    3.fastdfs的一些特性
    4.未来可能面临的问题
  

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

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