fastdfs Java版本的上传api中有多种方式，当初对众多的接口还是比较疑惑，最近仔细看了Java api的文档和测试源码，对slave mode的上传模式有了更深的了解。
fastdfs的slave mode应用场景主要是在应用层面的特殊需求，如一个原始图片有多份压缩图片（水印，缩略图）或者不同尺寸的文件，这样在原始文件上传完毕后，对由其派生的图片（切图）可以设定文件关联。

设置文件关联并不能节省fastdfs的存储，我能想到的好处就是在应用层面的处理上，可以节约下载地址的存储，如缓存和数据库资源，因为知道了原始图片的地址后可以拼出来其他格式的图片，根据需要任意调用，而不必为每个文件存储其下载地址。

如文件类型如下：

mypic.jpg（原始图片）
mypic_waterfall.jpg
mypic_thum.jpg
mypic_16x16.jpg
mypic_120x120.jpg

根据API
原始图片上传方式：

client.upload_file(local_filename, null, meta_list);

返回的remoteID

remote_filename: group1/M00/00/00/wKgE_lMOtqKAGnL2AACf6PqdpKk9691.gz

缩略图上传方式：

master_filename = remote_filename;   //获取原始文件的remoteID
prefix_name = "thum";  //指定prefix
client.upload_file(group_name, master_filename, prefix_name, local_filename, null, meta_list); //注意，这里的local_filename是根据原图切图之后新生成的图片
返回的remoteID
remote_filename: group1/M00/00/00/wKgE_lMOtqKAGnL2AACf6PqdpKk9691-thum.gz

基本就是这样，fastdfs通过client.upload_file的slave mode接口可以与master fileID建立关联，在应用层面起到了节约部分资源的作用。

本文固定链接: https://sudops.com/why-fastdfs-slave-file-mode.html | 运维速度