FastDFS合并存储的一个深层次bug排查
Posted Huazie
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了FastDFS合并存储的一个深层次bug排查相关的知识,希望对你有一定的参考价值。
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 返回该空间可用,但因文件同步延迟导致实际还在被其他文件占用)。具体如何引起乱序和冲突的,留给各位读者去思考。
4. 解决方法
问题的现象和原因找到后,解决方法就很容易了:指定 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
以上是关于FastDFS合并存储的一个深层次bug排查的主要内容,如果未能解决你的问题,请参考以下文章