基于FastDFS 5.03/5.04
2014-12-19
一、概述
FastDFS文档极少，仅仅能找到一些宽泛的架构文档，以及ChinaUnix论坛上作者对网友提问的一些回答。对于要将FastDFS应用到生产系统来说，这点了解绝对是不够的。
这段时间研究FastDFS源代码，而且做了大量的性能測试。中间也做了大量的笔记。基本上把程序的结构与基本的操作摸索清楚，因此写了一些文章即是对前段工作的总结，同一时候也分享给想很多其它了解FastDFS内部的同行们。
这里对每篇文章做个介绍。
1、机器之间的同步
Storage之间的同步可能是大家首先关心的了，这篇文章做了具体的介绍，最后我还写了注意事项。主要是性能方面的。
《FastDFS之Binlog同步》 http://blog.csdn.net/hfty290/article/details/42041155
2、加入新机器同步
大家可能不怎么会注意到这部分。可是事实上非常重要。
在实际的生产系统。坏掉一台机器，或者为了读压力而添加机器，等都是非常正常的。在一个执行的系统上加入一台机器涉及到存量文件的同步与融入到系统中。以下这篇文章做了具体的回答。
《FastDFS之加入机器同步》 http://blog.csdn.net/hfty290/article/details/42041953
3、磁盘恢复
线上机器坏个磁盘算是个大概率事件了，换了一个新磁盘。问题来了，数据怎么恢复啊。不用急，重新启动下Storaged。他会检測到并进行恢复，尽管恢复时间可能要非常长（数据量大时），这篇文章对这个功能做了说明。
《FastDFS之磁盘恢复过程》 http://blog.csdn.net/hfty290/article/details/42032817
4、Storaged程序结构
到此处Storaged基本的功能点已经讲述了。或者你还想知道程序内部是怎样组织的，线程之间的协调等信息，请看这篇文章。
《FastDFS之Storage程序框架》http://blog.csdn.net/hfty290/article/details/42048001
5、Client与Tracker的通讯
如今是时候从client角度来端详下Tracker了。由于无论是上传、下载、删除等操作都须要先查询Tracker。那么这些查询Tracker是怎样计算。并返回的呢？请看本篇。
《FastDFS之client与Tracker通讯》http://blog.csdn.net/hfty290/article/details/42064429
6、合并存储
海量小文件导致性能下降，可能大家都听说过。福音是FastDFS通过合并小文件成大文件的方式来规避这个问题。FastDFS是怎样实现这个功能的，具体请看这里。
《FastDFS合并存储原理分析》 http://blog.csdn.net/hfty290/article/details/42026215
7、Tracker-Leader选举
看过了《FastDFS合并存储原理分析》这篇文章后。对于当中提到的Tracker-Leader怎样选举可能会好奇，通过这篇文章你会看到Leader的选举过程。
《FastDFS之Tracker-Leader选择》 http://blog.csdn.net/hfty290/article/details/42030339
8、合并存储设计缺陷
对于FastDFS合并存储功能不得不面对一个问题，在某些情况下会导致数据错误或丢失。
你在看《FastDFS合并存储原理分析》这篇文章时可能已经发现了，如今让我们完完整整地重现下这样的错误的出现，请看。
《FastDFS之合并存储缺陷导致数据丢失或错误》 http://blog.csdn.net/hfty290/article/details/42030481