FastDFS合并存储Bug修复
本篇文章转载于FastDFS作者 余庆 大佬的 FastDFS分享与交流 公众号。
1. 问题
FastDFS V3 引入合并存储（trunk file）特性后，有用户反馈上传文件提示 trunk 空间被占用的问题。我在测试环境中经过一通测试，在极其偶然的情况下也能重现这个问题。然后就开始排查这个问题。
2. 分析
FastDFS 一个 group（存储分组）内有一台 storage server 被选举为 trunk server，用于管理和分配该组的 trunk 可用空间。为了高效管理 trunk file 的可用空间，我们使用了平衡二叉树 AVL。我们很自然地怀疑 trunk 空间管理和分配出了 bug。于是对管理和分配trunk空间的代码前前后后做了不下10遍的代码 review，直到看花眼了，也没有发现任何问题。也怀疑过 AVL 实现有 bug，于是写单元测试对 AVL 进行了大量测试，也没有发现任何问题。
这个问题很难复现，尝试通过代码 review 解决，但多次无功而返。合并存储这个潜在 bug 一直存在，导致合并存储存在风险，我心里很忐忑。
到了2017年初，我再次尝试解决这个困扰多年的 bug。既然代码排查没有任何效果，那就想办法重现吧。于是我开始通过小规模压力测试试图复现这个问题，通过上传和删除文件并行，问题终于得到复现，并且多次压测可以大概率复现。这次我盯住 trunk 空间分配的 binlog，写脚本进行分析和排查，发现 binlog 记录本身是正确的。但在发生 trunk 空间冲突的时间点，从 binlog 中发现一个 trunk 空间被回收后几乎立即就被分配出去了，我凭直觉抓住了这条关键线索。
继续 review 代码，然并卵，依然一无所获。业界有个说法我比较认可：问题能够稳定复现，就等于解决了一大半。在这么明显的线索的指引下，我终于转变了思路，开始思考这个成精的 bug 是否是多机环境导致的。然后。。。，经过反复推敲，我终于终于想明白了这个 bug 是如何被触发的了： 多机环境下操作时序问题。
以前的排查重心在 trunk 空间管理，经反复验证，这块是没问题的。问题在于一个 group 的多台 storage server 均可执行文件上传操作，而 FastDFS 对文件操作分发（复制）到其他存储节点采用异步方式，一个 trunk 空间的回收和再利用机制本身没有问题，但 storage server 在其 trunk file上存放用户上传的文件时，就可能会因时序问题而导致冲突（trunk server 返回该空间可用，但因文件同步延迟导致实际还在被其他文件占用）。具体如何引起乱序和冲突的，留给各位读者去思考。
3. 解决方法
问题的现象和原因找到后，解决方法就很容易了：指定 group 中的一台 storage server 上传文件即可。FastDFS 默认配置是轮流（round robin）上传到各台 storage server 的，通过 tracker.conf 配置文件中的 store_server 这个参数来设置。贴一下配置示例：
# which storage server to upload file
# 0: round robin (default)
# 1: the first server order by ip address
# 2: the first server order by priority (the minimal)
# Note: if use_trunk_file set to true, must set store_server to 1 or 2
store_server=0
千万不要小看Note这一句话，其背后是满满的辛酸和血泪啊！
补充说明一下，在开启合并存储，即 use_trunk_file 设置为 true 的情况下，为了避免上述乱序问题，若 store_server 设置为 0 的话，程序将强制调整为 1。
V3 最后一个版本是V3.11，通过查看 HISTORY 文件，其发布日期为 2012-08-04。直到 2017-03-29，终于修复了 trunk 文件空间偶发冲突的问题。
贴出 HISTORY 文件中的 changelog 为证（git log 也可以查到 ）：
Version 5.10 2017-03-29
* adjust parameter store_server when use_trunk_file is true
一个修复了约5年的bug，必须记录在案。
FastDFS项目地址： https://github.com/happyfish100/fastdfs
