凌晨 2:17，香港葵涌机房 8 楼，空调冷风直钻袖口。财务的结算文件又一次“卡”在 Windows 侧没能及时被 Linux 的风控服务捞到，CRM 同步延迟从 300ms 飙到 20 多秒，上海的同事电话一路打到我手机。指示很直接：“把这延迟打回到 1 秒内，今晚就要。”

我在机柜前蹲了 10 分钟，盯着交换机口的绿灯，脑子里把所有方案过了一遍：DFS、SMB 共享、rsync、Syncthing、Resilio、lsyncd、再到更“硬核”的 CDC（变更数据捕获）+ 流式总线。最后我决定——文件层用 Syncthing 做事件驱动的双向实时同步；数据库层用 Debezium 把 SQL Server 的 CDC 推到 Kafka，再进 Linux 侧的 PostgreSQL。

下面是我当晚到当天早上的全部落地过程，踩坑与优化一个不少。

1. 场景与目标

地点/网络：香港机房，两个同机房机柜，私有二层网络 + 公网冗余（BGP）。

平台：

• Windows Server 2019（核心业务应用、导出 NTFS 文件、主库 SQL Server）
• Linux（CentOS 7）上运行微服务、风控、报表、PostgreSQL

目标：

• 文件：Windows ↔ Linux 的目录级双向实时同步，端到端延迟 ≤ 1s；
• 数据库：SQL Server → PostgreSQL 的准实时（p99 ≤ 2s）数据流转；
• 安全：传输加密、仅内网直连、最小暴露面；
• 可观测：能量化延迟、吞吐、冲突率，出现故障能快速回滚/补偿。

2. 拓扑与硬件参数

注：CentOS 7 已过维护线，本文仍按现场环境写法落地（用户要求），但我在最后给了升级建议与替代方案。

3. 方案选型（为什么这么做）

文件层（近实时 & 双向）

• SMB/NFS + 轮询：改动小，但依赖扫描，细碎文件多时延迟不可控；跨平台权限映射麻烦；
• rsync/robocopy 定时：简单稳，但不是实时；
• lsyncd + inotify（Linux）⇄ Windows：Windows 侧事件捕获不如 Linux 顺滑；
• Resilio Sync：商用可，用过，速度不错；
• Syncthing：开源、跨平台，文件事件驱动（Windows 走 USN Journal，Linux 走 inotify），TLS 直连，冲突处理可视化，延迟最小。

结论：文件层选 Syncthing 做双向实时同步。

数据库层（结构化数据）

• 异构数据库复制：SQL Server → PostgreSQL 直连方案有限；
• ETL 批处理：延迟高；
• CDC + 流：SQL Server 开启 CDC，Debezium 抓取日志，进入 Kafka，再由 JDBC Sink 写 PostgreSQL，天然可追溯与扩展。

结论：DB 层采用 Debezium + Kafka 的 CDC 流。

4. 基线测量（优化前）

网络与存储

# Linux 侧 iPerf3 server
iperf3 -s

# Windows 侧（通过 WireGuard 内网或裸 10GbE）
iperf3 -c <linux_ip> -P 4 -t 10

同步延迟（旧方案 SMB + 定时轮询）

瓶颈：轮询扫描 + 防毒扫描 + 锁文件导致延迟不可预期。

5. 文件层实施：Syncthing 双向实时

5.1 网络打底：WireGuard 内网（可选但强烈建议）

虽然同机房，但我仍然拉了一条 WG 隧道，方便 ACL 与观察。

CentOS 7（Linux）

# 库与内核模块
yum install -y epel-release elrepo-release
yum install -y kmod-wireguard wireguard-tools

# /etc/wireguard/wg0.conf
[Interface]
Address = 10.77.0.2/32
PrivateKey = <LINUX_PRIVATE_KEY>
ListenPort = 51820
PostUp = iptables -A INPUT -p udp --dport 51820 -j ACCEPT
PostDown = iptables -D INPUT -p udp --dport 51820 -j ACCEPT

[Peer]
PublicKey = <WIN_PUBLIC_KEY>
AllowedIPs = 10.77.0.1/32

# 启动
wg-quick up wg0
systemctl enable wg-quick@wg0

Windows（WireGuard 客户端 GUI）

新增隧道，填入：

[Interface]
Address = 10.77.0.1/32
PrivateKey = <WIN_PRIVATE_KEY>
DNS = 10.77.0.2

[Peer]
PublicKey = <LINUX_PUBLIC_KEY>
AllowedIPs = 10.77.0.2/32
Endpoint = <linux_public_ip>:51820
PersistentKeepalive = 15

MTU 调优：如果外链不支持 9000，WG 内建议从 1420 降到 1380，再测丢包与吞吐，避免“黑洞”片段。

5.2 安装 Syncthing

Linux（CentOS 7）

cat >/etc/yum.repos.d/syncthing.repo <<'EOF'
[syncthing]
name=Syncthing - CentOS 7
baseurl=https://download.opensuse.org/repositories/home:/syncthing/CentOS_7/
gpgcheck=1
gpgkey=https://download.opensuse.org/repositories/home:/syncthing/CentOS_7/repodata/repomd.xml.key
enabled=1
EOF

yum clean all && yum install -y syncthing

# 建议创建专用用户
useradd -m -s /bin/bash syncuser
# 首次运行生成配置
sudo -u syncuser syncthing -generate="/home/syncuser/.config/syncthing"

# systemd 用户服务（包自带模板）
systemctl enable --now syncthing@syncuser

Windows

• 用 MSI 安装包安装 Syncthing；
• 通过 NSSM 或内置“服务化”方式注册为系统服务（建议使用专用服务账号，目录权限最小化）。
• 首次启动访问 http://127.0.0.1:8384 进入 Web UI。

5.3 关键配置（两端都要做）

①固定直连：

• 关闭全局发现（Global Discovery），只保留 WireGuard 私网地址（例：tcp://10.77.0.1:22000 / tcp://10.77.0.2:22000）。
• 监听端口：保持默认 22000/TCP、22000/UDP、21027/UDP（我们关闭全局发现后，21027 可禁）

②Linux 防火墙开放：

firewall-cmd --permanent --add-port=22000/tcp
firewall-cmd --permanent --add-port=22000/udp
firewall-cmd --reload

Windows 防火墙为 syncthing.exe 放行入站。

③文件监控：开启 Watch for Changes（USN/inotify）；

Linux 提升 inotify 限额：

echo fs.inotify.max_user_watches=1048576 >> /etc/sysctl.conf
echo fs.inotify.max_user_instances=1024 >> /etc/sysctl.conf
sysctl -p

④扫描间隔：设为 0–10 分钟（事件驱动为主，定期全量校验为辅）。

⑤并发与队列：

• Max Folder Concurrency 4–8（按 NVMe 与 CPU 调整）
• Pull Order: newestFirst（降低尾延迟）

⑥版本控制：启用 Staggered File Versioning，保留 10–20 个版本。

⑦忽略规则（两端一致，.stignore）：

# Office 临时、系统垃圾、日志切片
~$*
*.tmp
*.log.*
Thumbs.db
.DS_Store

⑧冲突策略：默认保留冲突副本（带 .sync-conflict-时间 后缀），冲突告警打到告警系统。

⑨防毒/安全：给 syncthing 数据库与工作目录加白名单，避免扫描阻塞 I/O。

5.4 目录映射与权限

Windows：将要同步的目录（例如 D:\export\settlement）赋予服务账号读写；

Linux：同路径（例如 /data/settlement）属主设为 syncuser；

跨平台大小写：避免仅大小写变化的重命名（Windows 不敏感、Linux 敏感），在 CI 中加规则或约束命名习惯。

5.5 实测延迟与吞吐（Syncthing 上线后）

到这里，文件侧的“实时”已经达标（我们的目标是 ≤ 1s）。剩下是数据库。

6. 数据库层实施：SQL Server → Kafka → PostgreSQL（Debezium CDC）

6.1 SQL Server 开启 CDC（Windows）

-- 开启数据库 CDC
USE master;
ALTER DATABASE MyDB SET RECOVERY SIMPLE; -- 视业务而定
EXEC sys.sp_cdc_enable_db;

-- 为表开启 CDC
USE MyDB;
EXEC sys.sp_cdc_enable_table
  @source_schema = N'dbo',
  @source_name   = N'Orders',
  @role_name     = N'cdc_reader', -- 可选
  @supports_net_changes = 1;

注意：SQL Server Express 版本历史上对 CDC 支持有限，生产建议 Standard/Enterprise/Developer。

6.2 Linux 侧：容器化部署 Kafka + Connect（CentOS 7）

# 安装 Docker CE（CentOS 7）
yum install -y yum-utils device-mapper-persistent-data lvm2
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
yum install -y docker-ce
systemctl enable --now docker

docker-compose.yml（核心服务）（示例，单机 POC，生产请按集群规划）：

version: "3.8"
services:
  zookeeper:
    image: confluentinc/cp-zookeeper:7.6.1
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
  kafka:
    image: confluentinc/cp-kafka:7.6.1
    depends_on: [zookeeper]
    environment:
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
  connect:
    image: debezium/connect:2.6
    depends_on: [kafka]
    environment:
      BOOTSTRAP_SERVERS: kafka:9092
      GROUP_ID: 1
      CONFIG_STORAGE_TOPIC: connect-configs
      OFFSET_STORAGE_TOPIC: connect-offsets
      STATUS_STORAGE_TOPIC: connect-status
    ports: ["8083:8083"]
  postgres:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: secret
    ports: ["5432:5432"]

docker compose up -d

6.3 注册 Debezium SQL Server 源连接器

curl -X POST http://localhost:8083/connectors -H "Content-Type: application/json" -d @sqlserver-source.json

sqlserver-source.json

{
  "name": "sqlserver-cdc-source",
  "config": {
    "connector.class": "io.debezium.connector.sqlserver.SqlServerConnector",
    "database.hostname": "WIN-SQL-IP",
    "database.port": "1433",
    "database.user": "cdc_user",
    "database.password": "StrongPassw0rd!",
    "database.names": "MyDB",
    "table.include.list": "dbo.Orders,dbo.Customers",
    "topic.prefix": "sqlserver",
    "database.encrypt": "false",
    "snapshot.mode": "initial",
    "poll.interval.ms": "500",
    "max.batch.size": "2048",
    "max.queue.size": "8192",
    "tombstones.on.delete": "false"
  }
}

6.4 注册 JDBC Sink 连接器（写 PostgreSQL）

jdbc-sink.json

{
  "name": "jdbc-sink-pg",
  "config": {
    "connector.class": "io.confluent.connect.jdbc.JdbcSinkConnector",
    "tasks.max": "2",
    "topics": "sqlserver.MyDB.dbo.Orders,sqlserver.MyDB.dbo.Customers",
    "connection.url": "jdbc:postgresql://postgres:5432/postgres",
    "connection.user": "postgres",
    "connection.password": "secret",
    "auto.create": "true",
    "auto.evolve": "true",
    "insert.mode": "upsert",
    "pk.mode": "record_key",
    "pk.fields": "id",
    "delete.enabled": "true"
  }
}

时延观测：我在 Kafka Connect 侧加了变更进入时间与落库时间的自定义 Header（也可在 Sink 里打时间），Grafana 面板取 p50/p95/p99，实测 p95 1.2–1.6s，峰值突发到 2.3s（GC 与批量合并时）。

7. 可观测与告警

• Syncthing：/rest/system/metrics 暴露 Prometheus 指标（或外接 exporter），重点看：
• pull_errors_total、file_deletes_total、folder_scan_duration_seconds、connected、folder_in_sync
• 系统：Windows PerfMon（磁盘队列长度/上下文切换）、Linux node_exporter
• Kafka/Connect：JMX Exporter → Prometheus，关注 sink lag、task status、rebalance 频率

SLO：

• 文件延迟 p95 ≤ 1s（以落盘时间对齐）
• CDC 落库 p95 ≤ 2s
• 告警：3 分钟内连续 5 次 folder_in_sync=0；sink lag > 5000 条，持续 2 分钟

8. 现场踩坑与解决

• MTU 黑洞：WireGuard 默认 1420，但底层某段只认 1400，出现间歇性卡顿。将 WG 接口 MTU 调到 1380 问题消失。
• Windows 防毒拖延：Defender 实时监控对 .stfolder 与 DB 目录扫描严重影响延迟。加白名单 后 p95 从 700ms 降到 380ms。
• 仅大小写改名：Windows 不敏感，Linux 敏感，导致“冲突文件”爆炸。CI 层面禁止仅大小写重命名，并在 Syncthing 告警后自动提交修复 PR。
• inotify 限额：千万级小文件目录直接把默认 8192 打爆，把 max_user_watches 提到 1,048,576 才稳。
• 文件锁：应用写文件采用 temp → rename 原子替换规约，Syncthing 忽略 *.tmp，避免半写文件被同步。
• Kafka Sink upsert 主键缺失：历史脏数据无主键，先跑一次清洗 补主键或改 pk.mode=record_value + SMT 提取字段。
• 时间漂移：NTP 没对齐导致延迟统计偏移，统一 chrony / w32tm 同步到同一上游。

# CentOS 7
yum install -y chrony
systemctl enable --now chronyd
chronyc sources

# Windows
w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /update
w32tm /resync

9. 效果对比（上线后）

文件侧

数据库侧（Orders 表）

10. 运维 Runbook（摘录）

文件同步异常（未 in-sync）排查顺序：

• Ping & iPerf3（检查 RTT/吞吐、丢包）；
• syncthing Web GUI 看连接是否直连（Direct/TCP）；
• Linux 查看 inotify 限额与进程句柄：cat /proc/sys/fs/inotify/max_user_watches、lsof | grep <path>；
• Windows Defender 日志与文件锁（Process Explorer）；
• 看 .stfolder 是否存在（目录标记丢失会重建）；
• 打开调试日志，关注 puller 队列与错误码。

CDC 延迟飙升排查：

• Connect 日志看 rebalance 与 task 异常；
• 主题分区与副本数是否匹配吞吐；
• Sink 端 upsert 主键与批量大小设置；
• SQL Server 端的 CDC 清理任务（sp_cdc_cleanup_change_table）是否落后。

11. 安全与权限

Syncthing 本身 TLS + 设备 ID 信任模型，仍建议：

• 仅内网直连（禁用全局发现/中继）；
• WireGuard/VLAN 隔离；
• 服务账号最小权限；
• 审计日志入 SIEM；
• Kafka/Connect：限制管理 API，所有 Connector 配置入 Vault/加密。

12. 成本与替代

开源栈（Syncthing + Debezium + Kafka）：0 许可费，运维成本略高；

商用（Resilio、GoldenGate、Confluent Cloud 等）：许可费 + 托管，换更低运维；

CentOS 7 升级：建议迁到 Rocky Linux 8/9 或 AlmaLinux 8/9，Docker/Kafka 支持更好、内核新，网络栈更稳。

13. 验证脚本（补偿/对账）

Windows PowerShell：对账校验（哈希）

param(
  [string]$Src="D:\export\settlement",
  [string]$Dst="\\linux\settlement" # 或本地挂载
)
Get-ChildItem $Src -Recurse -File | ForEach-Object {
  $rel = $_.FullName.Substring($Src.Length)
  $dstFile = Join-Path $Dst $rel
  if (Test-Path $dstFile) {
    $h1 = (Get-FileHash $_.FullName -Algorithm SHA256).Hash
    $h2 = (Get-FileHash $dstFile -Algorithm SHA256).Hash
    if ($h1 -ne $h2) {
      Write-Host "DIFF:" $rel
    }
  } else {
    Write-Host "MISS_DST:" $rel
  }
}

Linux Bash：快速差异清单

SRC=/data/settlement
DST=/mnt/win/settlement
cd "$SRC"
find . -type f -print0 | xargs -0 -n1 -P8 -I{} bash -c '
  f="{}"
  if [ -f "$DST/$f" ]; then
    h1=$(sha256sum "$f" | awk "{print \$1}")
    h2=$(sha256sum "$DST/$f" | awk "{print \$1}")
    [ "$h1" != "$h2" ] && echo "DIFF:$f"
  else
    echo "MISS_DST:$f"
  fi
'

14. 清晨 6:40 的绿灯

天快亮的时候，我在 Web 面板上看着最后一批对账脚本跑完，“in sync”的绿灯终于稳稳地亮着。上海同事发来一张报表截图，时间戳停在 380ms。
我把机柜门合上，像往常一样在机房的自动售卖机买了一罐温热咖啡——那晚我们没有换框架，也没有推翻历史系统，只是把“轮询”改成了“事件”，把不确定变成了确定。
后来每次上线新业务，我都会先问自己：这条链路的“事件”在哪里？ 能不能第一时间、最小代价告诉对端？大多数延迟问题，就从这句话开始被解决了。

15. 附：关键命令清单（速查）

# inotify 调优
echo fs.inotify.max_user_watches=1048576 >> /etc/sysctl.conf
echo fs.inotify.max_user_instances=1024 >> /etc/sysctl.conf
sysctl -p

# firewalld 端口
firewall-cmd --permanent --add-port=22000/tcp
firewall-cmd --permanent --add-port=22000/udp
firewall-cmd --reload

# WireGuard 启停
wg-quick up wg0
wg-quick down wg0

# Docker/Connect 查看
docker ps
curl http://localhost:8083/connectors | jq

总结要点（给赶时间的你）

• 文件层：Syncthing 双向 + 事件驱动，禁用全局发现，走私网，白名单防毒，inotify 限额拉满；
• 数据库层：SQL Server 开 CDC → Debezium → Kafka → JDBC Sink → PostgreSQL，监控 p95；
• 网络：能上 MTU 9000 就上，不行就收敛到稳定阈值；
• 可观测：延迟、冲突、lag 全链路打点；
• Runbook：把“最常坏的 5 件事”写成清单，凌晨时分不会慌。

如果你也在香港或其他机房面临类似的混合平台实时同步问题，这套组合拳能让你在一夜之间把延迟打回到可控范围；剩下的，就是把它变成标准化、可复制的“基础设施能力”。