文件存储相关的一些东西整理

       做App后端，特别是像IM这类，会有很多语音和图片之类的大大小小一堆文件在服务端进进出出.
这时，怎么存文件，就要好好想想了。
        其实文件存储这回事，我并不陌生，不过以前做存储备份开发时，更多关注的是文件同步，文件消重.
备份介质管理之类的东西。现在场景换了，不同了。

存文件大致有下面几种选择:
  1.直接保存在本地文件系统或网络文件存储上.
       本地磁盘太小，通常可以直接外挂存储，或用NFS之类网络文件存储。

            在产品验证或用户量小，OK的。备份管理也方便。

            如果用这种方案，有个小东西要注意，因为它是以一个个文件独立保存的，所以没法
     基于文件块消重，那么，就要尽量防止文件重复上传或存储。所以文件上传时记得做个Hash,
     然后以后上传时，可以先去查找文件HASH是否已存在，如存在，则说明文件已有，就不用在传了。

  2.自已找机器和存储，上分布式文件系统
     如果不自己开发(难度很大)，则开源的分布式文件系统太多了，我稍稍列一下我关注过的.
           2.1 FastDFS(C/C++开发)作者余庆(记得在易到用车当架构师)

                     FastDFS是一款类Google FS的开源分布式文件系统，它用纯C语言实现，支持Linux、FreeBSD、AIX等UNIX系统。

                    它只能通过专有API对文件进行存取访问，不支持POSIX接口方式，不能mount使用。

                    2008年7月发布，很成熟了。在CU上还有专门的论坛，资料很多很全。
                  它的问题是，如果文件数量太多，它的文件元数据会很大，因为它是通过文件夹散列的方式将文件直接存储在硬盘上面的.

  2.2 MongoDB的GridFs:
   如果上了MongoDB做记录(如JSON消息)存储，相关的文件存储在GridFs上，也顺道。
   GridFs的好处是能利用MongoDB现有的东西。但要是专门为了存文件而上GridFs，我觉得真没必要。

  2.3 Seaweedfs(以前叫Weedfs)/bfs   
     Seaweedfs(Go语言开发，作者Chris Lu) :   https://github.com/chrislusf/seaweedfs
     Seaweedfs 的设计原理是基于 Facebook 的一篇图片存储系统的论文 Facebook-Haystack
     说到这个，毛剑也在依这个论文写bfs, 正在开发中，可以跟看从小到大一步步完善的过程。
      https://github.com/Terry-Mao/bfs  

          FastDFS与Seaweedfs这类文件系统，就是为了存海量小文件而专门设计的。非常适用做APP的后台文件存储系统。
          用哪个看个人选择，要我，我会偏向Seaweedfs一些，
          1.它用Go,且出现的时间更晚。 
          2. 这有篇文件 <<分布式小文件系统fastdfs与weedfs的对比>> 可以看下
          
   4. 上第三方云存储，如七牛，又拍之类
       说到七牛，它的文件hash值算法是公开的，可以一看. https://github.com/qiniu/qetag
选方案时，看个人考量了。

    附一下Go语言处理文件上传的例子:
    astaxie： https://github.com/astaxie/build-web-application-with-golang/blob/master/zh/04.5.md

         

          其实纯从文件存储角度来说，上面方案都是小打小闹。就我知道的，目前业界最流行的PB级的开源的解决方案，

主要有两种: Swift与Ceph。

         Swift(Python)作为OpenStack组件之一，非常多的应用，记得有人说百度网盘底层也是用的这个.
         Ceph(主要用C/C++)则这一二年突然火了，很多公司(像雅虎)用Ceph替换了之前的方案。
这两者具体细节差异在哪就没去关注了，有兴趣的可以查查。


           文件存储这种东西，随着现在数据越来越大，越来越复杂了。牵进来的东西也越来越多，我也没跟进了(本来也没深入过)。
记得一直对有些数据同步开发中的疑问没解决耿耿于怀，知道UbuntuOne云存储开源部份代码(竞然是Python写的)后，很高兴，
终于可以看看别人是怎么弄的，结果，最后也就...., 洗洗睡了。


BLOG: http://blog.csdn.net/xcl168