FastDFS原理系列文章

一、概述

      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的通讯
      现在是时候从客户端角度来端详下Tracker了，因为不管是上传、下载、删除等操作都需要先查询Tracker。那么这些查询Tracker是如何计算，并返回的呢？请看本篇。
《FastDFS之客户端与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