说实话我最早接触文件监控与同步不是因为技术兴趣而是被一份日志备份的需求逼出来的。线上服务散在好几台机器上日志文件分散在各自的磁盘里每次排查问题都得一台一台登录上去翻折腾到半夜是常有的事。后来我想通了与其人肉同步不如让机器盯着文件变化再自动把变化的部分搬过去。就这一个朴素的想法最后串起了一整套文件监控与同步的体系。很多人听到文件监控与同步会以为这是两个东西拼在一起其实它们是一对强耦合的搭档。监控负责感知变化同步负责执行搬运但真正落地的时候你会发现难点全藏在两者的衔接处监控丢了一个事件怎么办同步还没完成文件又被改了怎么办监控脚本自己产生的临时文件会不会触发下一轮同步这篇文章我就按一个可行的落地路径来讲先拆清楚监控和同步各自的原理再给出可以直接抄的脚本和选型方案最后把部署后最容易踩的坑一个个列出来。1. 文件监控与同步的本质监控是看同步是搬1.1 文件监控的两种底层实现轮询与事件驱动文件监控通俗说就是让程序知道某个文件或目录什么时候变了。实现方式无非两大类一类叫轮询Polling一类叫事件驱动Event-driven。轮询的思路最简单每隔几秒扫描一遍目录比较每个文件的修改时间、大小、哈希值发现变了就处理。这个方案的优点是兼容性极好任何语言、任何系统都能做而且实现门槛几乎为零。缺点也非常明显第一浪费资源假设目录里有十万个文件即使一个都没变你每轮扫描都在白白消费CPU和磁盘IO第二时效性受轮询间隔制约间隔设短了费资源设长了漏掉快速变化的内容第三容易出现变化发生在两次扫描之间、但两次扫描看到的文件内容都是半截的尴尬情况。事件驱动则是完全不同的思路。操作系统内核在文件元数据或内容发生变更时主动向监听它的进程发送通知。Linux上的inotify、macOS上的FSEvents、Windows上的ReadDirectoryChangesW都是这个机制。程序不需要反复去问文件系统你变了吗而是注册好感兴趣的事件类型然后挂起等待内核会主动把变化推给你。这样做的好处是实时性高、资源开销小事件几毫秒内就能到达监听者CPU在空闲时几乎零负担。但事件驱动也有它的代价你需要处理内核通知的丢失、溢出、重复等问题需要理解不同事件之间的时序关系如果监控的目录层级很深、文件数量很大还需要对内核参数做调整。这也是为什么很多初学文件监控与同步的人写出的脚本看起来没问题、但实际跑几天就出现各种灵异现象——事件驱动不是简单调一个API就能完事的它的精髓在于对事件流的理解。1.2 同步的真正复杂度不在复制在状态再看同步。新手容易把同步理解为把文件从A盘拷到B盘如果你只是手动拷贝一次那确实简单但一旦做成自动化、持续化的同步复杂度立刻上升几个量级。第一个问题是增量识别。一个几百GB的目录如果每次同步都全量复制带宽和磁盘都受不了。所以同步工具必须能判断哪些文件是新的、哪些文件改过了、哪些文件被删了只传输变化的部分。这里就要依赖监控提供的元数据或者同步工具自己扫描比对。第二个问题是冲突处理。当源端和目标端在同一个文件上都做了修改该以谁为准是源端永远覆盖目标端还是保留最新修改时间的那一份还是把两个版本都存下来没有唯一正确答案取决于你的业务场景。单向备份和双向协作冲突处理策略完全是两套逻辑。第三个问题是事务性。同步不能只做一半如果文件拷贝到一半网络断了、磁盘满了目标端会留下一个不完整的文件。下次同步时你是接着传还是从头传是删除掉这个半截文件还是保留它等待修复一个成熟的同步方案必须在传输过程中使用临时文件、在传输完成后原子rename才能保证目标端任何时刻看到的都是一个完整状态。把这些想明白你就知道为什么文件监控与同步不能简单等同于写个脚本复制文件了。监控负责的是感知变化的精度同步负责的是状态收敛的可靠性两者必须配合才能形成一个可用的系统。网上很多开源项目看似功能简陋实际上在事件驱动、增量算法、冲突处理这些底层问题上花了大量功夫这就是它们能长期稳定运行的原因。2. 用 inotify 搭一套最小可用的文件监控系统2.1 inotifywait 的核心用法与参数Linux下做文件监控我首先推荐的工具是inotify-tools里的inotifywait。它把内核的inotify接口封装成了命令行工具写一两行Shell脚本就能实现对目录的实时监控。相比直接用C或Python调用inotify接口用inotifywait做原型验证和中小规模场景落地效率高很多。基础用法是inotifywait -m -r -e modify,create,delete,move /path/to/watch几个关键参数的含义-m表示monitor模式持续监听而不是监听一次就退出。-r递归监控子目录。-e指定要监听的事件类型常用的是modify内容修改、create创建、delete删除、move移动或重命名。--format自定义输出格式比如--format %w%f %e输出文件完整路径 事件类型。--timefmt配合%T在输出中显示时间比如--timefmt %Y-%m-%d %H:%M:%S。一个实测中最常用的组合是inotifywait -m -r --timefmt %Y-%m-%d %H:%M:%S --format %T %w%f %e \ -e modify,create,delete,move,close_write /data/app注意我特意加了close_write事件。初学时很容易只监听modify但modify在文件写入过程中会触发很多次往往文件刚写了一半事件就来了这时候你去同步它复制到的就是残缺内容。实际使用中更可靠的做法是监听close_write也就是文件被写入并关闭这个瞬间此刻文件内容通常已经是完整的。这是一个非常关键的实操细节很多人踩坑就踩在这里。如果你要监控的目录频繁产生临时文件比如vim编辑时生成的.swp文件、某些程序生成的.tmp文件不要等监控脚本输出后再用grep过滤更好的办法是直接让这几个事件源干净一点。但现实是程序不会听你的所以脚本里必须做过滤。2.2 事件过滤、去重与日志落盘inotifywait默认的输出是标准的stdout一行一条直接把输出重定向到文件就能得到一份审计日志。但我建议不要直接使用原始输出而是接一个过滤层。我先给一个示例脚本它做了三件事过滤临时文件、去重、写日志。#!/bin/bash WATCH_DIR/data/app LOG_FILE/var/log/file_watch.log inotifywait -m -r --timefmt %Y-%m-%d %H:%M:%S --format %T|%w%f|%e \ -e create,modify,delete,move,close_write $WATCH_DIR | while read line; do timestamp$(echo $line | cut -d| -f1) file_path$(echo $line | cut -d| -f2) event$(echo $line | cut -d| -f3) # 过滤临时文件 case $file_path in *.swp|*.tmp|*.bak|*~) continue ;; esac # 过滤隐藏文件可选 case $file_path in */.git/*) continue ;; esac echo $timestamp|$file_path|$event $LOG_FILE done这里的while read line循环是inotifywait脚本的经典写法。注意一个细节inotifywait命令如果遇到中断while循环也会退出所以需要配合nohup或systemd服务来保证持续运行。我一般习惯写成systemd service而不是裸挂一个nohup后台进程因为systemd能帮你管理崩溃重启。2.3 高频监控场景的两大隐患队列溢出和 inotify 上限事件驱动不是没有代价的。如果你的目录文件变动非常频繁比如每秒产生上百条事件而你的消费脚本处理速度跟不上事件就会在内核队列里堆积。当队列满时新事件会被丢弃inotify会发出一个IN_Q_OVERFLOW通知。这时候你的监控链路的实时性就已经失效了但Shell脚本很难第一时间发现。要规避这个问题内核参数是关键。两个最常需要调整的/proc/sys/fs/inotify/max_user_watches单个用户最多可注册的watch数量。默认值通常是8192对于递归监控一个大型代码仓库或数据目录完全不够。我一般会调大到524288设置方式是写入/etc/sysctl.conffs.inotify.max_user_watches524288 fs.inotify.max_user_instances512 fs.inotify.max_queued_events16384/proc/sys/fs/inotify/max_queued_events事件队列长度。默认16384左右如果单次事件洪峰太大可以适当调大但最终还是要靠消费端足够快。这里分享一个我踩过的技术坑一次监控一个包含10万文件的目录启动inotifywait时直接报Failed to watch ...: No space left on device。当时第一反应是磁盘满了排查半天发现根本不是磁盘问题而是max_user_watches不够。inotify的每一个watch都要消耗内核内存每个文件或目录至少一个watch10万文件就是10万个watch默认的8192上限当然不够。调大参数后问题立刻消失。另外还有一个实战提醒如果你在容器里跑监控容器的内核参数可能继承自宿主机但容器内看到的/proc/sys/fs/inotify/*不一定能改。这种情况要在宿主机上调或者在容器启动时用--sysctl参数指定否则一切努力都白费。3. 同步环节的三种典型方案选型监控做完就该考虑搬的问题了。同步方案没有银弹不同场景下的最佳选择完全不同。我按实际使用频率把方案分成三类单向镜像、双向实时同步、数据库与配置同步。3.1 rsync 实现单向镜像同步如果你的场景是源端数据变化后目标端要完整镜像一份比如日志集中收集、静态资源发布那rsync几乎是最稳的基石。rsync的核心优势是增量传输。它通过对比源端和目标端的文件元数据主要是修改时间和大小加-c参数则启用校验和对比来识别差异只传输差异部分。即便目标端已经有了一份完整副本首次同步之后的每次同步都只传新增或修改过的内容。一个常用的同步命令rsync -avz --delete --partial /data/source/ usertarget:/data/dest/参数说明-a归档模式保留权限、属主、时间戳、软链接等元数据。-v显示过程信息。-z传输时压缩。--delete删除目标端有而源端没有的文件注意这个参数有风险必须确认完全镜像就是你想要的行为。--partial保留传输中断产生的部分文件下次续传。关于--delete我特别想多说一句。刚开始我担心它误删数据不敢用结果同步出来的目标端全是历史残留文件磁盘越占越多。后来仔细分析发现只要源端目录是干净可控的镜像消除多余的删除反而帮我省了大量手工清理。但如果是多人协作、各自都可能产生独立文件的场景--delete要尽量避免否则A端删了一个文件B端的保留副本也会被清掉。3.2 Syncthing 实现双向实时同步需要双向同步的时候我会直接用Syncthing。它的设计初衷就是解决多设备之间的实时双向同步问题并且内置了冲突处理机制。Syncthing的工作原理是每台设备运行一个节点通过TLS加密通信它内部自己实现了文件变更监控会把本地的增删改事件推送给对端当同一个文件在对端也被修改时Syncthing会保留一个冲突副本而不是直接覆盖。它的几个特点决定了适用边界配置简单有Web管理界面跨平台支持好。双向同步天然适合个人文件多设备互通、小团队协作这类场景。它是全量同步模型没有单向上传这种语义如果想要的只是从A推送到BB永远不往A回传Syncthing其实不适用这种场景老老实实用rsync。需要说清楚的是Syncthing适合的是文件级的双向同步。如果你需要的是数据库这种有强一致性的数据同步它并不合适——数据库同步需要的是事务日志复制和一致性协议这不是一个文件同步工具能搞定的。3.3 数据库同步与配置文件同步的差异为什么单独说数据库同步因为很多人在搜索引擎里搜文件监控与同步真正想解决的问题其实是数据库怎么同步或者配置怎么同步这两者和普通文件同步根本不是一回事。先说数据库同步。MySQL的主从复制、PostgreSQL的流复制、Oracle的Data Guard底层的原理都是日志传输与回放——主库把binlog或WAL发给从库从库按顺序重放事务。这里面涉及到事务顺序、主键冲突、延迟监控、故障切换等复杂问题绝不是把数据库文件复制一份就能解决的。如果你看到有人想通过inotify监控数据库的数据文件目录来做同步我劝你立刻停止这个想法。数据库在运行状态下有自己的缓存和事务日志直接拷贝数据文件极大概率会得到损坏的数据。正确做法是使用数据库本身提供的复制机制或者像Canal这种基于日志解析的同步工具。再看配置文件同步。微服务架构里经常需要把配置同步到多台机器传统做法是用rsync或ansible推送配置文件但配置一变所有节点要重新加载这涉及到配置中心的问题。实践中更优雅的方案是引入etcd、Consul这类配置中心配置的同步由配置中心主动推送客户端监听变更后热加载。这比文件监控的思路又高了一层——后者本质上还是文件系统层面的感知而配置中心是应用层面的感知。做个简单对比总结场景推荐方案核心机制冲突处理单向备份/日志同步rsync增量对比传输源端覆盖目标端多设备双向同步Syncthing文件变更推送冲突副本数据库同步数据库复制/Canal日志重放事务一致性多节点配置同步etcd/Consul发布订阅版本管理4. 组合成一个监控触发同步的完整流水线4.1 架构与选型什么场景才值得事件触发很多人会问既然rsync本身就能增量同步为什么还要先做inotify监控然后再触发rsync直接用crontab每隔几分钟跑一次rsync不就行了这个问题的答案取决于你的需求精度。crontab的最小粒度是分钟级如果你能接受数据延迟一分钟甚至更久那确实不需要文件监控直接定时同步就好架构还简单可靠。但如果你需要在文件落盘后的几秒内就发起同步比如日志需要实时聚合、配置文件需要即时生效那你就需要事件触发。这里我建议按一个简单的判断标准选型数据量小、变更频率低、允许分钟级延迟直接用cron rsync简单可靠少写很多代码。数据量中、变更频率较高、要求秒级延迟inotifywait rsync但要处理好去重、回环和并发。数据量大且目录结构复杂、要求多设备一致直接上Syncthing这类成熟工具不要自己造轮子。数据要求强一致、有事务性别用文件同步去用数据库同步或消息队列。明白这一点就不会为了炫技在一个不需要实时的场景里强行引入事件驱动反而给自己制造一堆麻烦。4.2 用 shell 脚本把监控和同步串起来承接前面的inotifywait监控脚本我再把它扩展到监控到变更后触发同步的完整版本。#!/bin/bash WATCH_DIR/data/source SYNC_TARGETuser10.0.0.8:/backup/source LOG_FILE/var/log/sync_trigger.log LOCK_FILE/tmp/sync_trigger.lock inotifywait -m -r -e close_write,create,delete,move --format %w%f|%e $WATCH_DIR | while read entry; do file_path$(echo $entry | cut -d| -f1) event$(echo $entry | cut -d| -f2) case $file_path in *.swp|*.tmp|*.lock) continue ;; */.git/*|*/node_modules/*) continue ;; esac # 防重入防止上一次同步还没结束下一次同步又启动 if [ -f $LOCK_FILE ]; then echo $(date %F %T) skipped, lock exists $LOG_FILE continue fi touch $LOCK_FILE echo $(date %F %T) trigger sync for $file_path $event $LOG_FILE # 执行同步rsync 的退出码需要判断 rsync -az --partial $WATCH_DIR $SYNC_TARGET $LOG_FILE 21 rsync_rc$? rm -f $LOCK_FILE if [ $rsync_rc -ne 0 ]; then echo $(date %F %T) rsync failed rc$rsync_rc $LOG_FILE fi done这个脚本比纯粹的监控多做了几件事。一是用锁文件避免同步任务重叠。rsync对同一目录同时跑多个实例虽然不会把数据弄坏但会产生额外的IO开销而且并发时冲突行为不可控。用LOCK_FILE做防重入能保证同一时刻只有一个rsync在跑。二是在rsync后面等待其真正完成。事件触发的同步很容易犯一个错误inotifywait收到事件后立刻调用rsync但源端的文件其实是另一个程序正在写入的结果rsync复制了半截文件。刚才我在监控环节强调close_write目的就是让触发时机尽量靠近文件写完这个点但写作的程序也可能写完关闭后再次打开继续写所以最稳妥的方案是收到事件后稍微sleep一下比如sleep 1再执行rsync给慢速写入留出缓冲。这个技巧很土但实测能避免很多问题。三是加了退出码判断。很多人写Shell脚本不检查rsync的返回值网络断了、磁盘满了全被忽略日志里还一片安静。等到目标端数据对不上时再排查浪费了大量时间。退出码判断是底线。4.3 同步回环监控自身写入导致的死循环这是监控同步自动化里最隐蔽的坑新手很难意识到。你监控目录A发现文件变化后把它同步到B如果B恰好也在监控范围内同步过去的文件写入B时又会触发B的监控事件于是B也发起一次同步把文件传回AA再次触发……循环往复直到磁盘被刷爆或者你手动kill进程。解决这个问题的常见方式有三种方案一源和目标不要互相监控。看似废话但实际架构中源和目标往往就在同一台机器的不同目录或者同一网络内的两台机器上配置不当很容易出现互指。方案二在同步目标程序里排除同步工具自身产生的文件。比如rsync临时文件、Syncthing的冲突副本把这些文件名模式写进过滤列表。方案三在目标端的监控脚本里识别这个文件来源并跳过。比如rsync会在临时文件名后加.XXXXXX后缀收到事件时判断文件是否处于rsync的写入期Symcthing则会给自己的临时文件加后缀监听时过滤掉。我的实践经验是先用方案一从架构上避免互指再用方案二兜底这两个做到一般不会出大问题。方案三实现成本高除非特殊情况不建议做。还有一种类回环问题就是同步本身的写入会触发监控输出大量噪音日志。比如rsync同步到同一台机器的另一个目录本地同步监控脚本的inotifywait就会疯狂输出事件日志文件以GB级增长。如果确实要本地同步建议监控只关注源目录目标目录不要挂监控如果目标目录必须监控至少要在脚本里过滤掉*.tmp、*.partial这类rsync产生的临时文件模式。5. 部署之后我踩过的坑和排查链路5.1 事件丢失排查从队列溢出到磁盘IO监控脚本部署完第一天看似正常第二天发现漏同步了几个文件这是最典型的故障场景。排查路径我建议从下往上走。先用这个命令看当前inotify的实例和watch数量cat /proc/sys/fs/inotify/max_user_instances cat /proc/sys/fs/inotify/max_user_watches cat /proc/sys/fs/inotify/max_queued_events再看是否有队列溢出。inotifywait本身不会主动提示你队列溢出但你可以通过dmesg | tail看看内核日志有没有相关报错或者在监控脚本里做一个心跳机制如果超过N分钟没有收到任何事件就发送一个告警。很多情况下事件丢失的原因是消费端脚本处理太慢阻塞了inotifywait的输出读取管道最终导致内核queue溢出。这时候要做的不是调大参数而是优化消费逻辑比如把收到事件后的处理从同步改成收到事件后只做标记由独立worker来消费。另外磁盘IO饱和也会导致事件丢失。inotify事件是内核到用户态的通知但如果系统本身已经因为频繁IO而卡顿事件通知同样会延迟甚至丢失。这种场景下先解决IO瓶颈比调inotify参数更有用。5.2 文件锁与正在写入的误判即使监听了close_write也不能保证目标端拿到的文件一定完整。有两个现实原因第一很多程序写入文件时是写临时文件 rename两步走。比如Nginx、Redis的部分持久化逻辑就是这样。你监控到的create事件很可能看到的是临时文件随后move事件才是正式文件就位。如果你在create事件时就去同步同步到的是半截文件必须等到move事件或者干脆用close_write加延时。第二Windows或GNU程序有时会保持文件句柄打开写入关闭后又很快打开继续写。比如一个服务不断在尾部追加日志每次写入后都会关闭再打开close_write事件会频繁触发。你的同步逻辑如果是每次事件都完整传输一遍那在高频追加的场景下会造成持续的无效同步。我的解决方法很简单事件触发后引入静默窗口。收到事件后启动一个定时器如果500毫秒内没有新事件就认为文件稳定然后执行同步如果一直有新事件就一直延后。这个机制在代码里叫debounce在Shell里可以用一个小技巧实现。你也可以直接使用更成熟的工具比如SyncThing内部的cooldown机制就是这么设计的。5.3 增量同步的元数据与性能取舍最后说一个很多人容易忽略的性能问题当监控目录中的文件数量达到几十万、上百万级别时inotifywait的每次事件输出虽然很小但rsync每次去扫描对比整个目录的元数据这一下开销就大了。rsync的增量同步不是真的只传输变化部分它首先还是要scan一遍源目录和目标目录对比元数据找出差异。文件数量越大scan时间越长。如果你的监控触发频率很高比如每分钟触发一次而每次rsync的scan要花30秒那系统的同步就永远在scan根本谈不上效率。遇到大规模目录我的做法是在inotifywait收到事件时把变更的文件路径记下来同步时只针对变更的路径做rsync而不是每次对整个目录同步。利用rsync的--files-from参数把变更文件列表传给它实现精准同步。如果变更非常频繁退回到定时同步 事件标记的组合模式不要追求每个事件都立刻同步。# 伪代码使用 --files-from 只同步变更路径 echo relative/path/to/changed/file /tmp/changed_list.txt rsync -az --partial --files-from/tmp/changed_list.txt /data/source/ usertarget:/data/dest/这种方式的好处是同步量被严格限制坏处是如果多个文件连续变化你需要自行维护变更列表的合并与清理复杂度确实上来了。但从几十万文件规模的实际运行效果看这个投入是值得的。另外如果目标端也很大建议开启rsync的--itemize-changes日志配合定期的全量校验来发现增量同步产生的静默不一致。这个校验可以放在业务低峰期做避免影响主同步链路。文件监控与同步这套东西做起来不难做稳了不容易。我的经验是先想清楚你要的是秒级实时还是分钟级一致这决定了技术选型的复杂度然后再考虑监控丢了事件怎么办、同步和写入并发怎么办、回环怎么防这些边界问题才是真正决定系统可靠性的地方。把上面几个关键点处理好了这套体系基本就能稳定跑很久。