在现代 Web 架构中,为了应对高并发和实现高可用,我们通常会部署一个由多台服务器组成的 Nginx 集群。每台 Nginx 服务器都承担着分发静态资源(HTML/CSS/JS/图片)的重任。

然而,一个新的挑战随之而来:
scp 文件吗?答案显然是否定的。手动操作不仅效率低下,而且极易出错,是生产环境的大忌。
解决方案就是:使用 rsync + inotify 构建一套自动化、实时、可靠的文件同步机制。让代码一经发布,秒级同步到所有 Nginx 节点,实现真正的“一次发布,处处生效”。
? 核心价值:
通过 rsync 的高效增量同步能力与 inotify 的实时事件监听,将 Nginx 静态资源的部署从“人肉运维”升级为“自动化流水线”,大幅提升发布效率与系统可靠性!
在众多文件同步工具中(如 scp, sftp, ftp),rsync 凭借其独特的“增量同步”算法脱颖而出。
对于需要频繁更新但每次变更量不大的前端静态资源,rsync 是近乎完美的选择。
根据你的网络环境和安全策略,可以选择以下任一模式。
[CI/CD Server (Source)] │ ├── rsync ──→ [Nginx-01] ├── rsync ──→ [Nginx-02] └── rsync ──→ [Nginx-03]
[Nginx-01] ←── rsync ──┐[Nginx-02] ←── rsync ──┤[Nginx-03] ←── rsync ──┴── [Rsync Daemon (Source)]
✅ 本文将以更常用的 Push 模式为例进行详细讲解。
假设有以下两台服务器:
deploy-servernginx-web-01确保两台机器都已安装 rsync 和 inotify-tools:
# CentOS/RHELsudo yum install -y rsync inotify-tools# Debian/Ubuntusudo apt update && sudo apt install -y rsync inotify-tools
为了让同步脚本无需人工干预,必须配置 SSH 公钥认证。
在 deploy-server 上执行:
# 生成 SSH 密钥对(如果还没有)ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -N ""# 将公钥复制到 nginx-web-01ssh-copy-id [email protected]
验证免密登录:
ssh [email protected] "echo 'Success!'"
创建脚本 /opt/scripts/sync_to_nginx.sh:
#!/bin/bashSOURCE_DIR="/var/www/deploy/html" # 源目录REMOTE_USER="user"REMOTE_HOST="192.168.1.101"REMOTE_DIR="/var/www/html" # Nginx root目录# 使用 rsync 进行同步# -a: 归档模式,保留所有属性# -v: 详细输出# -z: 传输时压缩# --delete: 删除目标端已不存在于源端的文件# --exclude: 排除不需要同步的文件rsync -avz --delete --exclude='.git' --exclude='*.log' --exclude='node_modules/' $SOURCE_DIR/ ${REMOTE_USER}@${REMOTE_HOST}:${REMOTE_DIR}/if [ $? -eq 0 ]; then echo "$(date): Sync to ${REMOTE_HOST} completed successfully."else echo "$(date): ERROR! Sync to ${REMOTE_HOST} failed!" >&2fi赋予执行权限:
chmod +x /opt/scripts/sync_to_nginx.sh
为了让同步在文件变更后立即触发,而非依赖定时任务,我们使用 inotifywait。
创建守护脚本 /opt/scripts/inotify_sync.sh:
#!/bin/bashSOURCE_DIR="/var/www/deploy/html"SCRIPT="/opt/scripts/sync_to_nginx.sh"# 监听目录的创建、修改、移动、删除事件inotifywait -m -r -e create,modify,move,delete --format '%w%f %e' $SOURCE_DIR | while read file event; do echo "$(date): Detected change ($event) on $file" # 触发同步 $SCRIPTdone
使用 systemd 来管理这个守护进程。
创建服务文件 /etc/systemd/system/inotify-sync.service:
[Unit]Description=Inotify-based Rsync Sync for NginxAfter=network.target[Service]Type=simpleUser=userExecStart=/opt/scripts/inotify_sync.shRestart=alwaysRestartSec=5[Install]WantedBy=multi-user.target
启动并启用服务:
sudo systemctl daemon-reloadsudo systemctl start inotify-syncsudo systemctl enable inotify-sync
修改 sync_to_nginx.sh 脚本,使用循环遍历服务器列表:
#!/bin/bashSOURCE_DIR="/var/www/deploy/html"SERVERS=("192.168.1.101" "192.168.1.102" "192.168.1.103")REMOTE_USER="user"REMOTE_DIR="/var/www/html"for SERVER in "${SERVERS[@]}"; do echo "Syncing to $SERVER..." rsync -avz --delete --exclude='.git' $SOURCE_DIR/ ${REMOTE_USER}@$SERVER:$REMOTE_DIR/done直接覆盖正在被 Nginx 读取的文件可能导致用户下载到不完整的资源。最佳实践是采用“软链接+原子重命名”。
root 指向一个软链接,例如 /var/www/current。/var/www/releases/v20260621-1400。ln -sfn /var/www/releases/v20260621-1400 /var/www/current。ln -sfn 命令是原子的,能确保用户始终访问到一个完整、一致的版本。~/.ssh/authorized_keys 限制其只能执行 rsync 命令。command="rsync --server -vlogDtprze.iLs . /var/www/html",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAAB3...rsyslog 或 Filebeat 发送到 ELK/Splunk。inotify-sync 服务的状态,一旦崩溃立即告警。A: 有!默认限制可能很低(如 8192)。可通过以下命令查看和修改:
# 查看当前限制cat /proc/sys/fs/inotify/max_user_watches# 临时修改(重启失效)echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches# 永久修改echo "fs.inotify.max_user_watches=524288" | sudo tee -a /etc/sysctl.confsudo sysctl -p
A: rsync 本身对大文件的增量同步效果不佳。对于超大文件(如视频),建议:
proxy_pass 指向对象存储,利用 CDN 缓存。A: 不能。rsync + inotify 是一个轻量级的文件分发层,它解决的是“最后一公里”的同步问题。完整的 CI/CD 流程应包含代码拉取、依赖安装、构建、测试、打包、然后才是分发。rsync 应该作为 CI/CD pipeline 中的一个步骤来使用。