背景
我们公司在用inotify+rsync做实时同步,来解决分布式集群文件一致性的问题。但当web文件越来越多(百万级数量html,jpg等小 文件),同步就越来越慢,根本做不到实时,按照网上的调优方法都尝试过,问题根本没有解决。经过我一翻细致研究,终于把慢的核心问题研究明白,先总结一句 inotifywait响应不会有延迟,rsync也很快。大家同样有慢的烦恼,那是因为网上的inotify+rsync的教程都是坑。下面我们来分 析。
inotifywait 单独分析
1
|
/
usr
/
local
/
bin
/
inotifywait
-
mrq
--
format
'%Xe %w%f'
-
e
modify
,
create
,
delete
,
attrib
/
data
/
|
执行上面命令,是让inotifywait监听/data/目录,当监听到有发生modify,create,delete,attrib等事件发生时,按%Xe %w%f的格式输出。
在/data/目录touch几个文件
1
|
touch
/
data
/
{
1..5
}
|
观看inotify输出
1
2
3
4
5
|
ATTRIB
/
data
/
1
--表示发生了
ATTRIB事件路径为
/
data
/
1
ATTRIB
/
data
/
2
ATTRIB
/
data
/
3
ATTRIB
/
data
/
4
ATTRIB
/
data
/
5
|
知道上面的输出效果之后 我们应该想得到,可以用rsync获取inotifywait监控到的文件列表来做指定的文件同步,而不是每次都由rsync做全目录扫描来判断文件是否存在差异。
网上的inotify+rsync分析
我们来看网上的教程,我加了注释。(网上所有的教程基本都一模一样,尽管写法不一样,致命点都是一样的)
1
2
3
4
5
6
|
#!/bin/bash
/
usr
/
bin
/
inotifywait
-
mrq
--
format
'%w%f'
-
e
create
,
close_write
,
delete
/
backup
|
while
read
file
#把发生更改的文件列表都接收到file 然后循环,但有什么鬼用呢?下面的命令都没有引用这个$file 下面做的是全量rsync
do
cd
/
backup
&&
rsync
-
az
--
delete
/
backup
/
rsync_backup
@
192.168.24.101
::
backup
/
--
password
-
file
=
/
etc
/
rsync
.
password
done
|
#注意看 这里的rsync 每次都是全量的同步(这就坑爹了),而且 file列表是循环形式触发rsync ,等于有10个文件发生更改,就触发10次rsync全量同步(简直就是噩梦),那还不如直接写个死循环的rsync全量同步得了。
#有很多人会说 日志输出那里明明只有差异文件的同步记录。其实这是rsync的功能,他本来就只会输出有差异需要同步的文件信息。不信你直接拿这句rsync来跑试试。
#这种在需要同步的源目录文件量很大的情况下,简直是不堪重负。不仅耗CPU还耗时,根本不可以做到实时同步。
改良方法
要做到实时,就必须要减少rsync对目录的递归扫描判断,尽可能的做到只同步inotify监控到已发生更改的文件。结合rsync的特性,所以这里要分开判断来实现一个目录的增删改查对应的操作。